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”
I’ve been maintaining this development blog (on and off) for almost four years, now. In that time,I’ve managed to complete eight “game in a week” games (one of which went substantially over schedule), and one major other project. Professionally, I’ve
been a key member of the programming teams releasing three commercial console games during that time, and have had smaller roles on others. Also during the time since I started this blog, I spent about four months on vacation, about four months unemployed, and am now working for a new employer (where we’re only a few months away from our next commercial release)
In all this time, this blog has remained pretty much unchanged. I guess I was finally feeling like it was time to air the room and let in a little more light, so welcome to the new layout. Clean, simple, and relatively unobtrusive.
Of course, for those of you who read via the RSS feed, there’ll be no visible difference. But for everyone else, hopefully the site will be a bit easier on the eyes, particularly for my longer bouts of rambling.
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.
Remember a few weeks back when I talked about how pleased I was to have fixed a bug involving vertex normals when welding together the vertices of models?
Well, it turns out that I hadn’t fixed it at all; I’d merely hidden it in a few situations. As you can see from the screenshot on the left, the problem was still visible in other places (left corner of the graveship, top of the column, and more subtly, roof of the inn).
I believe that I’ve now well and truly solved the problem; certainly all those problem areas are now rendering more appropriately, as seen in the screenshot on the right. So yay. As I mentioned before, these fixes are in the “vsMeshMaker” utility class in the VectorStorm library. These fixes will be brought into the live trunk sometime in the next few days, once I’m satisfied that the bug is actually fixed for real this time, and hasn’t just scampered off to hide under some different rock.
In other news, I spent a good half hour trying to figure out why I haven’t been able to post thumbnails of screenshots since moving to the new server. Turns out that WordPress really wants to have php5′s gd module installed, and I had neglected to install that on the new server. Boo to WordPress’s support sites, which don’t mention that it needs this module.
In non-news, I’m still poking away at MMORPG Tycoon 2 and making (extremely) slow but steady progress. There hasn’t been much to show for a while, as I’ve been re-plumbing its innards to use regular VectorStorm library functionality wherever possible, instead of using custom rendering code everywhere. VectorStorm now supports out-of-the-box features (batched rendering, etc) which I had previously implemented explicitly within custom game-side rendering logic in MMORPG Tycoon 2. Simpler codebases lead to faster development! But simplifying codebases takes a lot of time. Especially when you’re doing it in your spare time.
So with three hours to go, I only have a few things left on my “to do” list:
- One sprite to add.
- One sound-effect to find and trigger
- Add instructions. (Probably will just be text floaters within the level, because that’ll be fastest to do)
- Maybe think about making the title screen less awful.
- Arrange the Windows build.
There were a few things I wanted to have in the game which simply aren’t going to get done in time, and the graphics are extraordinarily rough. But by and large, I’m kind of pleased with how this is turning out.
