Apologies; the following post is kind of technical. Those who are uninterested in this sort of fiddly technical stuff can safely ignore this post; it contains nothing at all relevant to game design. :)
A bunch of work under the hood of the VectorStorm engine, the past few days. It’s mostly invisible from game code, but produces better performance in general.
The first big change is that I’ve created a “vsCache” class, which can handle any sort of named, reference-counted game resource (textures, files, etc). It’s trivial to create these for anything you might want to keep cached or otherwise reference-counted. I’ve reworked both the “vsTexture” and “vsMaterial” systems to use the vsCache system. The system is, generally, invisible from the game code; you still create “vsTexture” and “vsMaterial” objects from code exactly as before, but now these objects look in the cache for existing data that they can piggy-back on top of, instead of always using up extra memory for something that might be a duplicate. This basically means that if you create sixteen identical vsMaterials, you’re not actually storing sixteen copies of the data any more, but only one.
Building on with that change, materials can now be loaded from text data files. To do that, you just create a vsMaterial, passing in the filename from which to load the material definition. Again, if that file has already been loaded into the cache, the engine won’t actually load the file, but will use the one which had previously been loaded.
Finally, materials now compile themselves into OpenGL display lists, which really speeds up the process of changing from one material to another while rendering the scene. (Still TODO is to consider trying to make the engine automatically batch materials together, so we don’t have to keep switching back and forth between materials. With the number of polygons I’m pushing through with each material right now, this would probably be a lot more work than it’s worth, so I’m not going to do it unless something easy occurs to me)
I’ve also fixed a couple of engine bugs. One annoying bug in particular involved how the file reading classes parsed unquoted strings, which caused some strings to vanish entirely before the game code had a chance to see them. I’ve fixed this bug in each “Game in a Week” game since Robot Finds Ice Cream, and keep forgetting to migrate the fix back into the core VectorStorm engine code. I’ll remember this time, I promise!
I’ve also added some facilities to make sure that singletons created by engine code are accessible by game code. All I’ll say here is that the C++ standards are basically non-existant about how static templated data should work when statically linking libraries together (and this has caused problems for me in optimised OS X builds, in particular).. so by pairing a hash table with RTTI information, I’ve created a mechanism to make the code do what I want it to, without relying on a particular behaviour from the compiler. (This was a critical fix, in order to get the vsCaches working)
I’ve also fixed an infinite loop bug in the vsHashTable, if there was a hash table collision. Silly bug, I’d overlooked it before just because I’ve never plugged enough data into one of these to make a collision happen, until now. And to my knowledge, nobody’s actually played with that before; it was just something I’d put together months ago while working on localisation support, which kind of fell by the wayside once the basics were implemented.
These engine upgrades and bug fixes are all in the MMORPG 2.0 codebase now; they have not yet been ported back into the public VectorStorm engine repository. But I’ll get to that within the next few weeks (once I’m really confident with them).
Also, I currently have about five essays about game design half-written. I should really finish one or more of those, so I can stop boring people with these painfully technical code updates.
