VectorStorm Blog

So here’s something new. It’s been annoying me for ages that I couldn’t make a 64-bit version of MMORPG Tycoon 2.  Or any VectorStorm game, for that matter.  Well, that ends today.

There was a surprising amount of work which went into making VectorStorm 64-bit compatible, but it’s all in place now, at last.

Not that I’m planning to have my games use more than 4 gigabytes of memory any time soon.  But having larger registers to play with does give some big performance wins, especially with the amount of memory copying that we do, managing renderable geometry buffers.

And I’ve spent most of today tracking down why, as part of this 64-bit project, suddenly all my textures were coming through differently than I expected.  Eventually tracked it down to a change in SDL_Image, which I use for loading textures (the change was only on the Mac side of the library, which explains why it wasn’t affecting my Win32 builds).  VectorStorm is now working with a patched version of that library.  (Hopefully that patch will be rolled into the next version of SDL_Image, which will be 1.13, I imagine)

Coupled with all this was discovering quite a lot of rendering logic bugs which (if I’m being honest with myself) I have no clue how they were working before.  Right now, I suspect that “sheer luck” is the answer.  But all is good now.  And now that I’ve reclaimed performance again, it’s time to get back to implementing game mechanics.  The screenshots I post will be much more interesting soon, I promise!

According to my colleagues at my new workplace, I am a ninja coder.

This isn’t a term with which I was familiar, before.  And after doing a little research to find out exactly what it meant, I certainly would never have been so bold as to have applied that label to myself.

But it’s incredibly flattering to have a workmate say it.

Over the past few years, it’s been becoming more and more rare for me to find myself using a laptop;  I seem to have settled back into desktop machines.  But every once in a while, I still find myself using my five-year-old laptop;  the one that I was using when I first started developing MMORPG Tycoon 2.

For the last week or two, I’ve been using it almost exclusively, often while watching television (or to be precise, while being in the same room with the television, but not actually watching it).  And this has shown me just how badly I’ve mucked up MMORPG Tycoon 2′s performance over the past year of development, as I’ve been coding on an extremely fast desktop machine.  As of just a few days ago, MMORPG Tycoon 2 wasn’t hitting 60fps on that five year old laptop, even in an empty game world.

So this week, I’ve been focused on performance.  And as a result, the average fps on that old laptop has risen from an average of about 40fps in an empty world to about 180fps in an empty world, without any changes to what’s actually being drawn.  This is making me feel an awful lot better!

Core performance notes:

1. Previously, I was dividing the local part of the world into a grid of 15×15 terrain tiles (225 tiles in total), each of which was rendering about 1,000 vertices.  Now I’m drawing the same amount of terrain, but dividing it up as a 3×3 grid of terrain tiles (9 in total), each of which is rendering about 25,000 vertices.  Lots of small draw operations are slow — much better performance to have a small number of big draw operations!  I preferred to use lots of small tiles because that made it faster to recalculate them when the terrain was being resculpted.  But now that those recalculations are being performed in a background thread, there’s much less reason to worry about how big the tiles are.  There’s still some tuning to do here;  3×3 is probably too few tiles to keep the world loaded nicely around where the player is.  Maybe I’ll try 5×5 and see how performance changes.
2. Drawing lines is ridiculously slow on some graphics hardware, including the GPU of my old laptop.  Anything I can do to limit the number of lines drawn will be worthwhile.  (must consider converting lines into rectangles manually, if I can work out a way to keep the apparent widths of 3D lines consistent on-screen, regardless of their distance from the camera)
3. Related to #2, I was drawing all the player’s action bars, even though normally only one or two of them are visible at any given time;  all the others were still being drawn, just slightly outside of the window frame.  Making offscreen action bars not draw themselves made a big difference to the frame rate.
4. Lots of UI code was still using the extremely old “compatibility” rendering architecture (which dates back to the earliest days of the VectorStorm library), and so it wasn’t taking  advantage of modern features like render buffers or the automatic material batching given by the relatively new vsFragment system.  I’ve now converted most currently-used UI code to use render buffers and fragments, instead of pushing explicit display lists and vertex arrays through the slower compatibility interface.

I think I’m now basically done with performance for the next little while.  So back to game features again!  I’ve been working on world editing a lot, but that’s not quite ready to be shown yet.  Maybe toward the end of this coming weekend.  We’ll see!

So today I fixed a whole bunch of minor bugs.  Folks who’ve been following the general game rules will remember that in MMORPG Tycoon 2, all art assets are brought into the game world through the respawn points;  the respawn points are where developers (other than yourself) enter and leave the game world.  As such, if you’re in an empty world, a respawn point is the only building you’re able to create.  At some point in the last few months, I apparently accidentally made it so that even the respawn points are unavailable if there is no respawn point for a developer to use to bring it into the game world.  Which means that in an empty world, you couldn’t build anything at all.  Oops!  Fixed now.

I also spent time fixing the “grassy mountains” problem, where all terrain surfaces in the game were being drawn with a grass effect (which is why I haven’t been close to mountains in any of my screenshots in a very long time).  This issue came in when I switched from old-style terrain rendering to the new (fast, and multiprocessor-aware!) style.  The modifications to VectorStorm’s VBO support which I mentioned a few days ago was in preparation for this fix, so I could actually vary the amount of clutter in a region without killing performance.

Sorry for no screenshot today.  Hopefully tomorrow I’ll have something screenshot-worthy!

Here’s a view of my development repository, with some of my commits from the last two days.

In the image, the interesting bit is the set of lines and dots running up the middle (under the “Graph” heading).  Each dot is a group of changes I made.  Each colour represents a different branch of development.  And the dots are arranged in order chronologically, with my most recent changes at the top.

So as you look from the bottom of the shot to the top, you can see branches branching off from the blue “master” development, and then later on being merged back into master.  (In fact, in the view here, I had two different branches both named “trees”, and which are both being drawn in yellow.  Despite having the same name, they were actually different development branches)

The fascinating thing (at least for me) is to see how much I’m working across different branches simultaneously — at most points on this graph, I have three different development timelines active at once.  As recently as three months ago, this graph was a single straight line, as every commit was just happening straight into the master development branch.

The interesting point is that in retrospect, I was working across multiple development paths back then just as much as I am now;  each commit was likely to be in an entirely different area, working on different projects at different times.  The difference is that now it’s organised in a sensible way.  It’s trivial to see which of my commits belong to which larger goal, and what larger goals are still in progress.  Even if I’m rapidly switching from task to task.  Previously, I had to manage all of these things in my brain;  now, the version control system helps keep track of it all for me.  Which frees me to think about the code, rather than about the implementation strategy.

It’s very difficult to imagine going back to a traditional non-intense-branching development methodology, now.  It’s not actually a change to how I develop — I was already madly jumping around between tasks!  The intense-branching approach just makes this development practice far easier to track and understand, when viewed from months later.