VectorStorm Blog

So I’ve just finished implementing a basic color picker control.  Here, I have it hooked up to the fog color.

Next step will be putting these into popups, so they don’t take up so much screen space.  These will be wired up to lots of things eventually (terrain, sky, object editors, etc), and I don’t really want them drawing at full size all the time.

I’m also starting to play with new GUI appearances — moving away from the “glowing lines over dark blue” theme that I’ve been using since the original release of MMORPG Tycoon.  Haven’t really picked anything specific yet, but I’m still experimenting.

Connected to this, I’ve added an HSV interface onto the vsColor class.  I’ll port that back into the VectorStorm trunk codebase soon.  Hopefully, this will be the last time I need to manually port these sorts of changes back;  the big restructuring of VectorStorm that I talked about in the previous post should make this unnecessary in future.

Short post today.  After the latest round of profiling, I’ve tracked down a few more performance problems and squashed them.

The screenshot is looking across a single MMO region, peppered with 1000 trees.  1000, because it’s a silly number of objects.  Trees, because they’re by far the most expensive model in the game right now.  The screenshot was taken on my almost-five-year-old laptop, and with all these trees being rendered, it’s still holding 30fps.  So I call that a victory.

There were two big slow bits to fix:

First, the material batching system was using templated container classes to store its batching information, and wrangling that data via the template implementation was much slower than it needed to be.  I switched to a hardcoded linked list implementation, and performance improved a lot.

But far bigger than that was the expense of collision testing.  Previously, every object in the region was being tested for collisions — both for the GraveShip and also for the user’s cursor.  With a thousand highly complicated tree models in the scene, that’s a lot of ray-vs-triangle testing.  So I’ve modified the collision testing to be performed using the region’s quadtree, so only the objects which are vaguely along the path being tested will actually do polygon-level collision checking.  So even in this absurdly busy scene, collision testing doesn’t show up at all in the profiling any more.

There’s still a little more that I could do.  For the most part, level placements (such as trees, buildings, etc) don’t move around, and so I could merge them together when they’re not being moved.  That might make a big difference.  Or it might not.

I’ve also played with doing level-of-detail calculations on the terrain, but reducing the number of terrain triangles doesn’t seem to actually lead to a faster render time.  I’d really like to get the frame rate up to 60 on this old laptop, but I’m happy enough with a solid 30 that maybe it’s not worth really fussing over too much.

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!

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!