Sprites are now working under Windows and Mac OS X. It was an ordeal to get the arcane workings of a PNG loader, PhysicsFS and OpenGL to work together in harmony but it's now displaying pretty pictures. I finally got glpng, a third party PNG-to-OpenGL library, to do the hard work for me after I adapted it to run using PhysicsFS instead of C streams. That makes a total of eight third party libraries just to render that sprite (SDL, Boost, TinyXML, PhysicsFS, zlib, libpng, glpng, and FastDelegate). And that doesn't count system libraries, OpenGL or the standard library.

That particular test shows a single sprite rotating in the centre of the screen. Here's the sprite test code to give you an example of where I'd like to go with this library:

This example is pretty simple and I expect the interfaces will change a bit as the library develops, but this is an idea of how I'd like to make the graphics system from the perspective of the game code. All that needs to be done is to create a Sprite object (that's my_sprite in this code), set the sprite type you'd like with its name, and on an update call perform whatever actions you need to do on the sprite. The graphics rendering system does all the display work behind the scenes; no call to or from the graphics module needed (except those implicitly included in the sprite, of course).

With a combination of PhysicsFS and some new code of my own I now no longer have to write a config file that states where all the image files are. The code will automatically find all the sprite sheets and load up the sprite names on initialisation.

In a more polished version the game objects won't hook up to the kernel directly; there will be a hierarchy of manager classes to deal with sets of objects in a structured way. I also need to implement the timing code to handle animation smoothly. But I'm very pleased with how this is going so far.