VectorStorm Blog

Today I set out to make trees be properly selectable.  Yesterday, it was very, very tricky to actually click on a tree;  they just seemed to mostly ignore the cursor, depending on which bit of the tree you clicked on.

Found the problem;  as it turns out, there were some bugs in the code which resulted in some of the pieces of the trees being ignored for collision;  you couldn’t click on them or stand on them.  But even once I had sorted that out, there were still many spots where the cursor simply wouldn’t be detected as moving over the tree.

Eventually, I tracked down the problem;  it was affecting scaled model elements, such as the various bits of foliage;  the VectorStorm matrix invert function had some pretty serious bugs in it, and that invert function was being used during the collision testing process.  Thanks to a friend, I managed to diagnose and fix up the matrix invert functions, and now everything is working well again.  The fixes are to vsMatrix4x4::Inverse() (and also affect vsMatrix4x4::Invert()).  vsMatrix3x3 was not affected.  These fixes will be migrated into the VectorStorm trunk in the near future.  (somebody poke me if I forget.. this one is important to actually get back into trunk)

I also found and fixed the problem which was causing strange rendering glitches at the top of each blob of tree foliage, which I mentioned yesterday.  This has highlighted how much more work there is to be done, in regards to generating texture coordinates for models.  The current system (by chance) works reasonably well for foliage, but needs a lot more work to support everything else I want to do with it.

Finally, I found and fixed a bug which was causing tree branches to gnarl excessively at their tips — often twisting a full 180 degrees or more, right at the end of each branch!  By and large, the tree generation is coming together quite well now, I think!

Actually, that’s a dirty lie.

Profiling is fun when it shows you something big that’s easy to fix.  Profiling is a lot less fun when everything is equally slow.  But luckily in my case, there was something big to fix.  :)

I noticed the other day that editing roads in MMORPG Tycoon 2 had become extremely slow.  (Well.. actually I noticed that roads didn’t draw at all.  It was only after I fixed them not drawing that I noticed that they were slow to edit).   This was odd, because I have videos of early road editing, where it hardly touched the frame rate at all on a system much slower than the one I’m using now.  So after some profiling, I found that creating their procedural geometry was taking up about 75% of the whole processing time for the frame when they were created.  This was extremely bad when editing them, especially (because they’re regenerated every frame, when they’re being edited, or when the ground under them is being edited).

Those of you who were at Freeplay will remember the part of my talk where I discussed optimising games, and when to do it (or rather, when not to do it).

For those who weren’t there, the tl;dr version is this:  don’t optimise anything unless you have timing numbers that proves it’s slow relative to the rest of your program, and against which you’ll be able to judge your progress.  Ideally, you get these numbers by using a profiler of some sort.  (Visual Studio has one built in, modern Xcode uses Instruments while old Xcode used Shark, under Linux you have gperf, etc)

What I didn’t say in that talk (and which I’ve regretted ever since), is that there’s a second criteria which can make it acceptable to optimise some code, even if you don’t have performance numbers.  Here is that other criteria:

Continue reading “Profiling is fun”

Just a couple quick notes today, because I really ought to be sleeping instead of posting.

Today, MMORPG Tycoon 2 has finally become a multithreaded game.  It’s not ubiquitous by any means, but it’s taken the first step;  the ground clutter is now being generated in a background thread.  The only bit of clutter-related code which is now occurring in the main thread is copying the final geometry into the buffer that OpenGL renders from.  Now all the setup work as you move around the map is being handled in separate threads.

This means a couple of things.  For one, it means that MMORPG Tycoon 2 can finally use a little more of the CPU time from everyone with a multi-core computer (which is just about everyone with a computer from the last six years or so), and it also means that as more tasks can be moved out into other threads, I’ll be able to do more and more processing without hurting the game’s frame rate.

I’ll also note that Mac OS X’s support for semaphores is half-broken, and Win32′s support for semaphores is bizarre and generally unrelated to traditional semaphores.  Makes me a sad coder.  (for the non-coders in the audience:  semaphores are a tool for synchronising multiple threads, to help keep them from stepping on each other’s toes)

More details tomorrow.  Or later today, I guess, technically.  And semaphores will eventually be ported back into the VectorStorm trunk, if anyone wants to look at them.  Also fixed some bugs in the vsTask class, and added features to the vsMutex.  Will need to move all those changes back to the live trunk in the near future.  Maybe over the weekend.

So here’s a fun one for you all.  I mentioned that I had achieved some speed boosts for rendering based upon insights from gDEBugger.  On the basis of that, I’ve been setting up some more intelligent rendering code which doesn’t tell OpenGL to do something that it was already doing.

In brief, what was happening before was that MT2 (and all VectorStorm games) would render every object in the scene one at a time, setting up OpenGL to render that object individually (“Turn fog on.  Turn lighting on.  Turn zbuffer on, turn writing into color channels on, turn glow effect off, etc.”), even though 95% of those settings were the same on every object in the scene.

Now what happens is that each object registers those state changes onto a new object (the “vsRendererState”), and immediately before rendering, all those queued state changes are made.  Previously if (for example) the first object in a scene is using a texture and the second object is also using a texture, I’d be telling OpenGL “okay, turn on texture support”, render the first object, then “turn off texture support now”, and then “okay, turn on texture support again” before rendering the second object.  Now, it leaves texture support on until it actually starts rendering an object which isn’t using a texture;  it only changes the settings which are actually changing, instead of just naively setting everything.

Note that to make this work, I had to remove compiled display list support.  There’s simply no good way to keep track of OpenGL’s internal state when compiled display lists are being used.  But compiled display lists were really replaced by VBOs long ago, so this shouldn’t cause concern.  It’s similar to when I removed CPU-side shaders, and overlays.  Old technologies which have been superceded by faster, better ones.  :)

The screenshot today is what happens when there’s a bug in the code (in this case, not applying rendering state changes before performing post-render effects).

The Windows version of the new VectorStorm multithreading code is now in place and working, and in the live trunk.  (Has been for about week, now;  I apparently forgot to post about it!)

I’ve also been playing a bit with gDEBugger, an OpenGL profiler/analyser/etc, which is now free (was previously quite expensive to license).  It’s nowhere near PIX in terms of power and insight, but it’s as close as we have under OpenGL at the moment.  And you can’t argue with the price.  And it works on all the major platforms, which is pretty awesome to see.  I’ve already made some sizeable rendering speed boosts for VectorStorm just on the basis of its insights into MMORPG Tycoon 2, and will have more in the near future.  Once I have these mostly sorted out, I’ll port them back into trunk as well.

This tool has also pointed out that lots of the techniques VectorStorm’s core rendering architecture use have been declared obsolete as of OpenGL 3.1.  Which surprised me, since I kind of designed VectorStorm for OpenGL 1.4 (which was the most that my ancient laptop could handle at the time);  I really didn’t think that the interfaces I was using would last all the way up to 3.1!  But it does suggest that someday I should be thinking about looking forward to the more modern revisions of OpenGL;  purging some of my old rendering architecture, and replacing it with more modern approaches.  That won’t be until after MT2, though, unless MT2 really calls for some modern rendering techniques.  (I’d really like to have some basic shadows.  But otherwise, I’m not too fussed over fancy rendering techniques for MT2).