Apologies for all the similar screenshots lately; it’s what happens when I’m working on the behind-the-scenes tech, instead of new features.
So I’ve finally finished converting the world across to being generated in a background thread. This means that as the player moves around the world, there are no longer any frame rate stutters as new blocks of terrain are created in front of the player. I’ve also dramatically simplified the world rendering code, which comes as a tremendous relief.
So now that I’m not worrying about performance, I’m going to be diving back into more detailed world-building. Which should mean more interesting screenshots in the near future!
Just got back from Freeplay. I think my talk went relatively well; had a painfully dry throat until some event organiser kindly brought me a bottle of water, and it took the audience a little while to warm up, but we eventually got there. I got through all the topics I wanted to cover, and I don’t think I made myself look too silly in the process. :)
Paul Callaghan’s crowd-sourced “unKeynote” concept seemed to be a huge success. I’d like to be the first one to call for its return in future Freeplays, even if funding is available to bring in a more traditional keynote speaker.
Anyhow, I’ll be back at FreePlay again tomorrow, just listening to sessions. And tonight? Tonight I’ll probably play some Bastion, before getting some early sleep.
For anybody in or near the Melbourne area, just a quick side-note that I’ll be speaking at FreePlay next weekend, discussing my favourite subject: how code can affect player perceptions of a game. There’ll be some re-covering of stuff from VGKnowHow, and a lot of new stuff as well. My session goes from 14:45 – 15:45 on Saturday, August 20th, at the State Library of Victoria. There are further details, for anyone interested.
Tickets to FreePlay are $35 for access to the conferences and workshops.
If you’re in the vicinity, drop by and say ‘hi’!
Feels like I’ve been working on clutter for ages and ages. And from a certain point of view, I guess I have. These clutter systems are kind of a simpler version of most of the rendering parts of MMORPG Tycoon 2; creating and destroying renderable geometry when it’s needed, so we don’t have a ridiculous amount of geometry just sitting around in memory all the time, not being used. This is an important consideration, when your game world is the size of World of Warcraft! The stuff I do here will eventually generalise out to the height map, and then (hopefully!) to most other procedural geometry int he game, and should make the game feel a lot more responsive.
So today I’ve done phase two of the multithreading of clutter. Yesterday, each “clutter tile” kept its own thread which would sleep while waiting for a “build some new clutter” job to arrive. Today, there is now just one “worker thread” which handles all clutter rebuilding tasks. This behaves a lot more nicely (particularly for people with fewer cores on the CPU), and should scale a lot better. And it’s noticeable faster again to rebuild tiles of ground clutter, even compared against how fast it was yesterday. From my point of view, the system side of ground clutter is now basically finished. All that remains to do is to generate different types of clutter depending upon the terrain type (right now, it generates grass on everything, even bare mountain faces)
The plan is that tomorrow and over the weekend, I’ll be bringing this same system over to edge clutter, and to the base height maps as well. This should substantially improve the frame rate jitters that I currently get when a new block of world terrain comes into view.
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.
