Getting Skype to work on Debian Jessie.

This seems to be a difficult task if the Google results are anything to go by; the .deb is to old and pulls in obsolete dependencies and does not install on the more recent Jessie versions. So,  just a quick outline of what I did to get Skype to work on my Jessie box.

1> Download Skype - the dynamically linked version, not the Debian 7 version.
2> Enable multi arch for i386 as per the Debian MultiArch Howto.
3> sudo apt-get install libXv1:i386
4> sudo apt-get install libXss1:i386
5> sudo apt-get install libQtDBus4:i386
6> sudo apt-get install libQtWebKit:i386
7> sudo apt-get install libgl1-nvidia-glx:i386

..then skype should be able to run, with all dependencies satisfied. The last step is only because  I am running with binary blob "official" Nvidia drivers. I imagine for other systems you should install the appropiate libgl1 package (usually the mesa version).

The Endless Quest for the Great Common Lisp Game

I have decided to revive my quest for the Great Common Lisp Game (abbreviated to TGCL).

 There are a number of reasons for this. Firstly, on the personal level the current day gig is heavyweight C++, and Common Lisp is a pleasant counterpoint to the tyranny of the Compile-Link-Edit cycle.

Secondly, the Lisp Commons has improved immensely over the last few years, thanks mainly Zach Beane and his efforts with Quicklisp.

Thirdly, the indie games scene has changed out of all recognition since the time I was trying to boot something; should I get to the point where I have something viable a pleotrha of funding options exist where there were none before. As a corollary with the third point, the nature of what I'm competing with has changed - I'm no longer competing against AAA developers with deep pockets, but people with a Unity3D liscence and more artistic talent than I can ever hope to have.

Most importantly, on the fifth hand ( we are counting on Lisp Alien hands ), I still have the deep suspicion that games development with Lisp looks deeply unlike anything with C++. I recally in the early days of my education as a Lisp neophyte that I was impressed with the GRT raytracer I was surprised to find that it was an abandoned project. I was even more surprised when I spoke to the author and he told me the reason for abandonment was that it "wasn't lispy enough.". This flipped a few relays on the cerebral switchboard: if a conventional raytracer architecture isn't "lispy enough", what of conventional game engine architecture? I'm not at all sure, but an extended bout of exploratory programming might be in order. So, onwards...

More fun with EProject

I am really enjoying using Jonathan Rockway's Eproject for Emacs. It's project management done in a minimalistic way that lends itself to many useful elisp hacks. As well as the scons/flymake project definition that I use, there's also a nifty hack that allows header/source file definition switching that I just cooked up.

It's only a few lines long but already useful. It's simple because eproject will simply list all the files in the current project for you, then you can pick out the duplicate...

Scaling Emacs

I just finised a short stint working on UE4. One of my problems was Emacs. It just isn't scaling for the kind and size of projects that I have to tackle. UE4 is much more decomposed than UE3 and there are dozens and dozens of directories to tag. While Exuberant Ctags is an excellent technology for tagging source, it's slow to run over many, many directories.I need an intelligent daemon that can watch directories for change and re-run ctags as needed.

The second problemis that analysing source isn't the only route to finding semantic information these days: both the JVM and .NET support reflection - and this is the preferred route to find things like type names, function signatures, etc. Some code has to be written that can reflect on assemblies and class files and be fed into a tags database or auto-completion solution so that the class libraries can be discovered interactively.

I'm hoping there are open source projects there that would get me at least halfway to this functionality.

The third problem, which I'm likely to tackle myself is flymake. Flymake is predicated around the assumption that full builds are too expensive to do, and selective builds of a single file, in order to check it are the way to go. This does not fit with many build tools which manage large amounts of dependencies on a big project and build only the one changed file in any case. When flymake originated this was far too an expensive an operation to be performed interactively, but in a world of multi-gigabyte memory, and sixty-four-bit multicore this is no longer true. So I'm going to change that aspect of it.

Any more suggestions welcome.

Building SDL_image for Android

SDL 2.0 for Android is coming along nicely - although it still has no support for NativeActivit There are good build instructions for it in the repository.

Adding SDL_image to the mix wasn't as simple as just copying it to the jni/ directory and calling "ndk-build". Doing so yielded this error:

jni/SDL_image/IMG_jpg.c:34:21: fatal error: jpeglib.h: No such file or directory

Logically enough, SDL_image needs libpng, libz, and libjpeg to build.Fortunately - as a time saver - you can still grab copies of these on on the libSDL website. You can then copy jpeg/ and png/ into the jni/ folder and: "ndk-build clean", followed by "ndk-build" to rebuild.

EDIT: It turns out there's a more recent framework here. All you will have to do is update the Android.mk in jni/src with the libraries sources you use, and be sure to load the right libraries in SDLActivity.java, of course.

Exporting FBX from Blender to UDK

While playing about with Blender 2.63a I discovered that it is now possible to export from Blender to the UDK via FBX. At present I'm not sure of the limitations: I set up a test animation with Rotation keys only, the armature origin at 0,0,0 and the mesh origin at 0,0,0, with no scaling. I ran the exported FBX through the FBX Converter for FBX 2012.2  to convert it into a binary: (as Blender's FBX exporter seems to export an antique version of FBX that the UDK takes exception to). To my surprise the converted FBX imported into the UDK fine - last year this was a sure fire recipe for disaster; something must have changed.

This screenshot shows the animation part of the process, adding keys one by one in pose mode. Note I use the LocRot keyset; it's very unlikely that the toolchain will support scale keys; so I haven't tried this. Armature and Mesh are centered on the origin (for the mesh this can be achieved by Object|Apply|Location and Object|Apply|Scale.

Add caption

SCons and Flymake.

Getting Emacs's flymake-mode to work with SCons was surprisingly easy. It needs some extra elisp in your .emacs to invoke flymake, which can be lightly adapted from the existing makefile processing, and a small check in the SConstruct to see if the process has been invoked by flymake itself. In my case, I arrange for a command line flag SYNTAX=1 to be passed from Flymake to SCons. For example..

The Emacs side involves some lightly edited versions of flymake functions in the .emacs as the scons command line is as make-like as it's sanely possible to be; a design goal of the SCons guys

The main drawback of this method is that it does not check header files directly, as SCons does not process them as they produce no direct build products. This leads me to suspect that SCons is not really the correct tool for this job; although a env.SyntaxCheck command could probably be rigged up: another post for another day.

EDIT: After some more work on this, I got header files working. The snag is that I've had to customise flymake-master-file-dirs to be relative to the directory in which include files are found include in my case. Which is probably not ideal - they should be relative to the buildfile.