Voxeliens is a retro-style arcade shooter for the PC, in which you defend your planet from waves of descending enemies. The gameplay is simple and fast paced as you battle your way through different environments using a variety of powerups. Think Space Invaders would have been better in 3D? You’re right, so download the demo and play the first few levels for free… then buy the full game for just $3.99!
I’ve been hard at work over the last few weeks to iron out some of the main blockers to the Linux port of Voxeliens. One of the major hurdles I’ve been coming up against is the the dangerous area that is ABI compatibility on Linux.
Posted by milliams on Jun 18th, 2012
For those that don’t know, an ABI (application binary interface) is what allows you to use existing libraries of code in your application, whether they’re things you’re in control of (like our PolyVox library) or system libraries (like glibc or the C++ standard library). For the purposes of the discussion here, an ABI is defined by the symbols that a library contains where symbols are things like functions. As a library evolves over the years they will add functions and each time a release of the library is made with new symbols the library ABI version will increase. Most library developers (and this is particularly true of system libraries like glibc) will promise to never remove any symbols from their libraries which means that an application built against an old version of glibc will still work when run on a new system as all those symbols will still be present (this is called forward compatibility).
The opposite cannot be said to be true. If you build an application on the latest greatest version of your favourite Linux distribution it will freely try to use newer symbols in its dependent libraries. If you then copy that executable to an older distribution and try to run it, it will balk and complain that it can’t find the required symbols. There are tricks one can play to trick the compiler into only using symbols from an old ABI version but the simplest way to achieve the goal is to install an old distribution in a virtual machine and compile all your code there.
This is what I’ve been doing for the past few weeks. I created a VM with a 32 bit installation of openSUSE 11.1 (released December 2008) and have recompiled Voxeliens and all its dependencies in the most minimal way I can. The reason I am doing this in a 32 bit VM rather than a 64 bit one is that 32 bit binaries (technically i686) are compatible with 64 bit operating systems (technically x86_64) whereas the inverse is not true. Ideally these binaries built in the 32 bit VM will work on any Linux OS released in the last 3 or 4 years regardless of whether it’s 32 or 64 bit. This will be one of the main things we’ll need testers for when the time comes.
For low level system libraries there’s little choice apart from building against an old version. However, for higher level libraries we have more options. For some libraries with liberal open source licenses we can simply statically link them which essentially involves bundling the library’s code directly into the final executable – thereby avoiding and ABI problems. Any library under a license like the GPL or LGPL, however, cannot legally be statically linked and so the simplest solution here is to include the library file along with the game and tell the executable to use the bundled version rather than any provided by the system.
Shaders are complete
David’s done some excellent work to port all the shaders over to GLSL. In the last update you saw that there was nothing there but flat colours but now everything, including shadows and lighting is working.
What’s left to do?
So now that the building of a portable version of Voxeliens is complete, there’s a few areas that need finishing before it can be released:
Once these are sorted, it will be ready for testing among a wider audience and we’ll put out a request for beta testers nearer the time.