VectorStorm Blog

So here’s a fun one for you all.  I mentioned that I had achieved some speed boosts for rendering based upon insights from gDEBugger.  On the basis of that, I’ve been setting up some more intelligent rendering code which doesn’t tell OpenGL to do something that it was already doing.

In brief, what was happening before was that MT2 (and all VectorStorm games) would render every object in the scene one at a time, setting up OpenGL to render that object individually (“Turn fog on.  Turn lighting on.  Turn zbuffer on, turn writing into color channels on, turn glow effect off, etc.”), even though 95% of those settings were the same on every object in the scene.

Now what happens is that each object registers those state changes onto a new object (the “vsRendererState”), and immediately before rendering, all those queued state changes are made.  Previously if (for example) the first object in a scene is using a texture and the second object is also using a texture, I’d be telling OpenGL “okay, turn on texture support”, render the first object, then “turn off texture support now”, and then “okay, turn on texture support again” before rendering the second object.  Now, it leaves texture support on until it actually starts rendering an object which isn’t using a texture;  it only changes the settings which are actually changing, instead of just naively setting everything.

Note that to make this work, I had to remove compiled display list support.  There’s simply no good way to keep track of OpenGL’s internal state when compiled display lists are being used.  But compiled display lists were really replaced by VBOs long ago, so this shouldn’t cause concern.  It’s similar to when I removed CPU-side shaders, and overlays.  Old technologies which have been superceded by faster, better ones.  :)

The screenshot today is what happens when there’s a bug in the code (in this case, not applying rendering state changes before performing post-render effects).

The Windows version of the new VectorStorm multithreading code is now in place and working, and in the live trunk.  (Has been for about week, now;  I apparently forgot to post about it!)

I’ve also been playing a bit with gDEBugger, an OpenGL profiler/analyser/etc, which is now free (was previously quite expensive to license).  It’s nowhere near PIX in terms of power and insight, but it’s as close as we have under OpenGL at the moment.  And you can’t argue with the price.  And it works on all the major platforms, which is pretty awesome to see.  I’ve already made some sizeable rendering speed boosts for VectorStorm just on the basis of its insights into MMORPG Tycoon 2, and will have more in the near future.  Once I have these mostly sorted out, I’ll port them back into trunk as well.

This tool has also pointed out that lots of the techniques VectorStorm’s core rendering architecture use have been declared obsolete as of OpenGL 3.1.  Which surprised me, since I kind of designed VectorStorm for OpenGL 1.4 (which was the most that my ancient laptop could handle at the time);  I really didn’t think that the interfaces I was using would last all the way up to 3.1!  But it does suggest that someday I should be thinking about looking forward to the more modern revisions of OpenGL;  purging some of my old rendering architecture, and replacing it with more modern approaches.  That won’t be until after MT2, though, unless MT2 really calls for some modern rendering techniques.  (I’d really like to have some basic shadows.  But otherwise, I’m not too fussed over fancy rendering techniques for MT2).

A bunch of little technical updates today.

First, I’ve updated the VectorStorm engine so that it’ll compile successfully against iOS SDK v4.3.  I’ve also got both the standard VectorStorm Testbeds and MMORPG Tycoon 2 compiling under the newly released XCode 4.  My opinion of XCode 4 is complicated;  I can understand the general outcry from many developers, but there’s lots of cool stuff in there too.  Whether the cool stuff outweighs the concerns, I’m not really sure.  But for the next couple of days, I’ll be using XCode 4 as my day-in day-out compiler to see how well I adapt.

Second, I’ve begun implementing some threading primitives into VectorStorm.  These are not yet compiling under Windows (since Microsoft has an entirely different threading model than UNIX-based systems), but I do now have both mutexes and threads working under OS X.  I’ll get the Windows version working tomorrow.  These little tools are going to be critical for MMORPG Tycoon 2, due to the amount of processing that it has to do;  it’s just going to be a lot easier to put some of that work into a separate thread.

Do be aware, though, that none of the rest of VectorStorm is written to be threadsafe.  These multithreading classes should really only be used for simple tasks that don’t involve calling into the various VectorStorm libraries at all.  If you have lots of calculations to be done in the background, then that’s fine.  But probably best not to try to allocate memory or start playing sounds from inside a thread or anything.  :)

For the first time since getting my new job, I’ve finally sat down and written a little code on my home projects.  It’s not too much, but it felt pretty good to write it.

I’ve fixed the VectorStorm engine bug which was causing problems with the middle mouse button and right mouse buttons (often swapping the two, or causing them not to work at all).  It was an embarrassing mistake;  I had just mis-assigned labels for the controls, causing some minor swapping when loading saved control preferences.  I’ve made this bug fix both within MMORPG Tycoon 2 (where it was a major problem), and within the trunk VectorStorm library (where it was less of a problem, since no standard VectorStorm games were using mouse control).  If any of you have been looking at or using the VectorStorm library, you should go get those fixes.  If not, don’t worry about it too much, just be aware that I’m back to the compiler again.  :)

I’ve also begun poking with Tycoon code again.  Not a whole lot;  am just slowly easing myself back into it.

Maybe it’s just me.  But I’m completely paranoid about MMORPG Tycoon 2 ending up looking something like this;  an endless expanse of identical trees, sprouting from all sorts of improbable places, in the middle of a simple height map that manages to look matte and unlit, despite the presence of a directional light.

I’m not sure precisely what I need to do to avoid this, since the sort of asset re-use that was key in making this awful vista is also going to be required in MMORPG Tycoon 2.  Maybe if there were any sort of shadows being cast it’d help.  Or maybe if the trees weren’t quite so awful.  Or if the rocks weren’t simply amorphous blobs wedged into a monochromatic height map.  I don’t know.  I saw this vista in a modern MMO the other day, and was immediately seized by the terror of “how do I avoid creating this, myself?”

Anybody have thoughts?