VectorStorm Blog

I was ill for part of last week, so haven’t made quite the progress on items that I wanted to.  But I’m starting on the work needed for cascaded shadow maps, for really nice full-world shadow support.

The first requirement for this is to be able to render an orthographic projection.

Orthographic projections are actually pretty simple;  they’re a view which has no vanishing point;  objects don’t appear larger as they get closer to the camera, or smaller as they get further away.  Oddly enough, this is the traditional sort of view used for most “tycoon”-genre games.  The screenshot here is of a regular view into the MMORPG game world, taken from an orthographic camera.  And.. I think I kind of like it, once real shadows are in.  I’m starting to think about using this sort of view for general terrain editing and building placement modes, then going down into first-person perspectives for non-editing modes.

Until now, the VectorStorm library had no native support for orthographic views;  you could either render a flat 2D space, or you could render a perspective projection of a 3D space.  I’ve now added support for orthographic views to the vsCamera3D.  There are a whole host of changes under the hood which are needed to make use of this.  But the upside is that you can now ask a vsCamera3D for its projection matrix;  that’s no longer hidden inside the renderer.

To use an orthographic view, set a camera’s projection type to “vsCamera3D::PT_Orthographic”, and set its field of view to the vertical distance you want to be rendering.  The horizontal distance is automatically determined based upon the field of view and the aspect ratio (exactly as we were already doing on the vsCamera2D).

Tomorrow, I’ll be hooking up a couple of shadow map renders to this sort of view.  With any luck, I’ll get all the way through and be able to show demos of proper shadowing.

This post isn’t actually about shadows.  But after poking around a bit, I’ve finally got shadows performing nicely.  Look at that timing bar at the bottom left corner of the screenshot, and compare it against any of the recent screenshots (with or without shadows) to see how little a performance difference is being caused by the shadows, now.

As I mentioned yesterday, there’s still a lot to do with shadows.  Most notably, right now shadows are only being generated for a single area of the game world (covering about half of the starting region).  Move away from there, and shadows vanish again.  I’m planning to implement cascaded shadow maps, which will result in shadows being calculated near the player, and with better resolution near the player;  blockier further away.  I’ll make an attempt at this on the coming weekend.

But what I really want to talk about today is the screenshot from yesterday, with all the red squares in the actionbars.  In a lot of ways, for me, those screenshots are more exciting than these ones with the progress on shadows.  See, what’s going on is that I’m in the middle of a massive refactoring of how action bars work.  And here’s why:

I’m adding an inventory.  Both for in-game characters, and for the player himself.  “Items” are now objects which can be carried around, and optionally perform a function when clicked upon.  And almost everything is now an infinite-use “Item”, including all of the terrain editing and building placement tools.  Even the button for stepping off of the graveship is an “Item” now.  Similarly, the various combat abilities of mmo classes are now implemented as infinite-use items, too.

Items are stored in various places (inventory, class abilities, etc), and shortcuts to these items can then be dragged into action bar button slots.  I haven’t yet implemented stacking and depletion of similar items, but that’s planned;  hopefully should have that working by the end of the week.  This support gives me the ability to (for example) give the player once-off consumable items, such as “construct a capital city”, without cluttering his interface with disabled buttons for all the time when he’s not allowed to do that.  It also opens the door to, for example, the player being able to de-rez a building, pick it up, carry it somewhere else, and then rebuild it elsewhere, at no charge.  I think I like that mechanic a lot more than the current “drag the building freely around the landscape” interface.

In a more obviously useful vein, it also allows the MMORPG game to have things like health potions, spell scrolls, and other one-use items, and have the AI players automatically understand how to use them.  These consumable items are all implemented in exactly the same way as class abilities, which means that they should slot straight into the AI action selection logic that already exists.

Originally, the idea for MT2 was to abstract away items, because of all the complexities that surround them (drop tables, loot frequencies, etc), but in the end, I really wanted to be able to give items to the player for the purpose of building the world.  I probably won’t expose the complexities of drop tables in the first release of MT2;  it’s not really what I want the game to be about.  I’ll just have AI game designers fill them out automatically.

So that’s what I’m up to at the moment!  Hoping to polish off the item interface this week, and get cascaded shadows over the weekend.  Wish me luck!

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.

So I’ve spent much of the weekend working on adding to VectorStorm’s shader support.  Enough that I’ve managed to implement dynamic shadow maps in MMORPG Tycoon 2.

This is all very early stuff, and I’m sure that I’m going to want to completely rework the mechanisms by which this works.  But I’m pretty pleased at having things which are recognisably shadows in the game!  (And interacting nicely with the grass effect, etc!)

This isn’t ready for prime time yet.  It’s still very, very glitchy, and is far too computationally expensive for what it is right now (because I’m rendering into a 2048×2048 shadow texture).  And I’m not even certain that I really want shadows for the visual style of the game.  But it’s nice to finally have VectorStorm supporting them!

Also, MMORPG Tycoon 2 is now using my de-facto VectorStorm library development trunk, which is over at Github.  Which means that if you want to see the changes under the hood, they’re all publicly visible right now;  no need to wait for me to port them back from the MT2 codebase to the VectorStorm trunk.  (Note that there are no testbeds or samples demonstrating anything using this;  it’s just source code for the rendering architecture, and therefore probably not of much interest to anyone)

Notable new stuff includes:

• VectorStorm games can now implement custom frame drawing logic (defaults to old behaviour, if they don’t).
• VectorStorm now supports offscreen render targets, for television screens, shadow buffers, and other purposes.  Render targets support multisampling buffers and depth-only targets, in addition to normal texture targets.
• Games can now request individual scenes or groups of scenes be drawn into a special render target.
• Games can now override the normal lit/unlit/textured/untextured shaders with their own custom shaders.
• Game-provided vsShaders are now able to set uniform variables and otherwise set up their state, when they’re used.
• vsImage can now read back texture data from a vsTexture object (even one inside a render target).

This is a screenshot of the first run of MMORPG Tycoon 2 running under Linux.  It’s built via a cmake setup — the same script which builds on Windows and Mac.  And it’s building from a VectorStorm library trunk that’s shared with the Testbeds samples.

The big troubles all came from the fact that MacOS X and Windows don’t care about the case of filenames, while Linux does.  So the three compile errors I had were all from files #including other files, and making a mistake about capitalisation.

In terms of game itself, the Linux build mostly — mostly — worked straight out of the tin.

• Input works (although the cursor — particularly the right mouse button — feels a bit sluggish to respond.  This may be due to running in a virtual machine;  must try this on a real Linux box).
• All current game mechanics appear to work.
• Loading and rendering of textures work.
• The bloom rendering shader works.
• Secret game mode #3 works.