I released MMORPG Tycoon 2’s Milestone 7 build on December 7th; that’s just under six weeks ago. In that time, I’ve made 200 commits to the codebase; that’s an average of about 5 commits per day. That’s only counting changes made to the game itself; not ones made to the publicly available VectorStorm game engine (66 changes made to the VectorStorm engine during that time period), and there have been some reasonably large game engine changes.
For example, during this period the VectorStorm game engine has switched from generating random numbers using the Mersenne Twister, to using a simple xorshift random number generator (specifically, xorshift1024* ). Additionally, it adds support for multiple random number sources in a single program. This now makes it possible to safely (and repeatably!) generate sequences of pseudo-random numbers from multiple threads simultaneously (by giving each thread a separate random number source).
Also in this period, VectorStorm’s has begun to use the shockingly badly named PhysicsFS library for (wait for it)… loading and saving files. What else would you expect a library named “Physics” to do? Anyhow, this gives us a bunch of benefits, including unifying code for loading and saving files across different operating systems, for finding appropriate file directories for saving user files, and for allowing end-users to modify game files (e.g..: to support modding by users)
VectorStorm has added support for specifying separate colors per instance, when drawing instanced models. In MMORPG Tycoon 2, this functionality is being used for much quicker drawing of trees, clouds, and water ripples.
In font drawing, we now support aligning text by its top, by its baseline, or by its center. That’s in addition to the normal left/right/center justification settings. And in addition to the fixes to pixel-exact font rendering, when centered that I posted about earlier.
VectorStorm also now has (early) support for shared OpenGL contexts. This means that you can (for example) render your scene from one thread, while feeding new data into OpenGL via the second context, from a background thread. Most folks won’t need to do this, but in a game which does as much background generation of data as MMORPG Tycoon 2, it makes a big difference!
Finally, I’ve begun to deprecate the old method in which VectorStorm assembles rendering command queues for the basic vsModel and vsSprite classes; no longer does it insert OpenGL 1-style “push” and “pop” matrix instructions into the queue; now everything is done by calculating the correct final matrix, and setting it with a “set matrix” instruction. This one change has dropped the size of the rendering commands for a typical MMORPG Tycoon 2 frame from about 300kb to about 40kb.
Plus, VectorStorm is now starting on a path to make it easier to use shaders from game code. You can now set custom shader uniform values on your material (only floats and bools are currently supported, but more will be added as soon as I’m sure I have the code architecture approximately right). The values you specify will be sent to the shader before your model gets drawn. No more need to create a custom ‘shader’ class in order to set uniform values! Values may either be set to a constant value, or may be bound to a memory location so that you can update values at any time, and the shader will automatically notice the changed value the next time it draws your material.
Oh! And for the first time in ages, there’s a new basic system preference available. VectorStorm now supports disabling its support for HighDPI displays (defaults to disabled). When disabled, VectorStorm pretends that window manager ‘points’ are pixels. When enabled, VectorStorm will draw using the display’s native pixel density. I finally got annoyed at my Macbook Pro Retina’s high-density screen, but mobile-class video card which couldn’t quite push all those pixels. And I imagine that this will be an issue for most devices which have HighDPI displays. But if you want to use absolutely all of your pixels, support for that is easy to turn back on. :)
Those are the most notable changes in the VectorStorm engine since the last milestone build. (They’re all public over on Github, licensed under an extremely permissive zlib-like license, so feel free to look over it, adapt it, use it, or whatever!)
MS8, on the other hand, has more than three times as many commits as the VectorStorm engine itself. So suffice to say, the change log for Milestone 8 is probably going to be massive. I expect that I’ll be spending most of tomorrow just writing it up! But most of Milestone 8’s changes don’t affect the core game itself, which is almost identical to what was present in Milestone 7; instead, it mostly affects the overall game structure, polish, UI flow, and packaging.
Two days left to go, and Milestone 8 will be out the door! I’m very much looking forward to completing this one, and getting back to working on the core game itself, again. :)
