Today, a completely different view.  What you’re seeing on the left is the VectorStorm testbed samples compiling (or more accurately, failing to compile) under Ubuntu Linux.

It’s mostly working, actually.  All of the rendering code is compiling successfully (which is a major relief!)  The bit that’s failing right now is something that’s including headers through the Box2D library.  The memory management functionality I use often conflicts a bit with Box2D and other libraries, since I’m trying to take over control of malloc, new, new[], free, delete, and delete[], replacing them with my own implementations.  Which does sometimes cause problems.  Not yet sure what’s causing this particular instance of the issue, but I’m sure I’ll figure it out eventually.

My plan is for the next version of the VectorStorm library to work across four platforms:  Mac, Windows, Linux, and iOS.  It’s substantially cleaned up compared against what I’m using now in MMORPG Tycoon 2, and will generally make my day-to-day development a lot, lot simpler.  But there’s still a little ways to go before it’s ready to go.  Once it’s done, I’ll be splitting it off into a shiny new git repository which has never been polluted by big music files, so will be much, much smaller on disk.

Big issues (apart from “make it compile”) that I still need to sort out:

1. Figure out the future of Box2D within VectorStorm.  Do I continue to embed it within my source control repository, as I always have?  Or do I switch to using it as an external library, the way that I do with SDL and GLEW?  I’m leaning strongly toward turning Box2D into an external library.  And maybe setting up some sort of system which allows it to be excluded entirely.  Because honestly, most of my games don’t use it at all.  Seems silly to have it as a dependency for games that don’t use physics.  On the other hand, I worry about its API potentially changing, which would mean I’d have to pay more attention to it than I do now, potentially updating the bindings with each new Box2D release.  Or maybe I should remove the Box2D bindings entirely, and let individual games deal with it themselves.
2. Figure out SDL/Glew header #include conventions.  On OS X, Glew is expected to be in <Glew/Glew.h>.  On Win32/Linux, it’s expected to be in <GL/Glew.h>.  Similarly, on OS X, SDL_image is expected to be in <SDL_image/SDL_image.h>, while on Win32/Linux it’s expected to be in <SDL/SDL_image.h>.  Right now I’ve worked around this by having separate #include lines for different platforms.  But this feels a bit absurd.  I might simply switch to <Glew.h> and <SDL_image.h> (respectively), and handle the directory within CMake rules.  But then the source code won’t match any platform.
3. Figure out how to handle SDL/GLEW frameworks on OS X.  I really don’t like checking binary builds of them into version control, but there’s no other good way for Mac users to get them;  these projects don’t provide frameworks.  I had to manually configure projects to build them against the right SDKs and for the correct architectures.
4. Implement semaphore support on Win32.  Somehow I forgot to finish this in the initial implementation of threading for Win32.
5. Test threading support under Linux.  (Theoretically, the OS X code I’ve written should work under Linux without modification.  But it needs testing to verify.)