A boring screenshot

Originally, my plan for this weekend was to implement cascaded shadow maps for MMORPG Tycoon 2.  In practice, though, technology had other plans for me.

Some background:

VectorStorm’s graphic engine works based on a concept that I call display lists (OpenGL programmers, these are not the same thing as OpenGL’s display lists).  In VectorStorm, a display list is a set of rendering commands, converted into a binary blob of memory.  You can think of them as a small program that is run by the renderer.  Statements in these programs are things along the lines of “Activate the texture ‘grass.png'”, “Draw this list of triangles”, “Draw a line between these two positions”, etc.

Originally, VectorStorm’s drawing strategy was to create a display list, and pass it around to all the drawable objects in the world, letting each of them put their own drawing commands into that list.  In practice, though, switching from one type of material to another (e.g.: switching from drawing clouds to drawing grass) is much more complicated and time-consuming than almost anything else, and so I added a class which I call a Render Queue.  The Render Queue basically keeps a separate Display List for each material.   So when objects submit their “here’s how to draw me” instructions to the renderer, they’re added to a render queue for the materials that they’re using.  This means that, for example, we only need to set up the tree foliage material once, no matter how many trees are visible on the screen.  In the world of graphics technology, this is called batching — rearranging drawing commands to try to make them run faster.  This made a huge difference to rendering performance.  It also gives me a lot more control over specifying which objects are drawn in front of other objects, for things which don’t use the z-buffer.

For backwards-compatibility, the Render Queue also keeps a “Generic Display List”, which old code can use the same way that it used the original display list.  But that tends to be a lot slower, and has a lot more draw-ordering issues.

Almost every one of the “Testbeds” games, for example, still uses the Generic Display List for all their drawing.  But MMORPG Tycoon 2 is attempting to perform a lot more drawing and needs to perform more optimally, so almost everything in MT2 is now rendering using the batching system.  (In the screenshot above, only the MMORPG name, the bars beneath it, and the timing bars in the bottom left corner of the screenshot are still rendering via the generic display list — absolutely everything else is being rendered using the batching system)

Or at least, that’s what I thought.

This morning I discovered that absolutely everything in VectorStorm’s 2D rendering path was still using the Generic Display List, not the batched rendering system, even if the game was requesting the batched rendering system.  I had helpfully left myself a little comment that I should turn on the batched rendering for 2D, which was nice of me.  But there were some technical challenges in getting it up and running.  The largest of these was that I’m still sticking with VectorStorm’s weird coordinate system, which required some serious doctoring of matrix math to make it all work with OpenGL.

The long and the short of it, though, is that I now have 2D objects being correctly batched, the same as 3D objects.  This should give a sizeable speed boost for folks on slower GPU processors;  the 2D drawing in MMORPG2 has always been a much bigger drain on GPU performance than the 3D drawing, so anything that can help it out a bit will definitely help a lot.

I’ve got more stuff to talk about (particularly the reason for the red squares in the picture above), but I’ll leave that for tomorrow.  I’ve already babbled for far too long, tonight.

And maybe I’ll manage to do the cascaded shadow maps next weekend;  it’s too big a task to really attempt in my spare time during the week.