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.