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!