Mommy's Best Games, Inc. is a small, private game developer founded in 2007. This site is to share some of what goes on behind the scenes with the creation of our games.
You can click any of our game titles on the right, from Serious Sam Double D XXL to our first, award-winning title Weapon of Choice. There's also categories on the right side if you scroll down some and of course a Search option.
Feel free to contact me if you need more game information!
Thursday, July 24, 2008
The fourth and current version makes the game faster and is a combination of methods. When using XNA on the Xbox 360 you have access to four hardware threads (1, 3, 4, 5) and a one thread for the main game application (thread 0). With that in mind, my update threading uses four threads to update all game objects simultaneously. The new design gives each thread one quarter of the level objects in succession. That's important, because the longer each thread can run uninterrupted, the better.
Some profiling output for the 360 was set up using StopWatch. In addition, I have a boolean that can be toggled by a controller button combination. Without threading the update takes around 25ms. With the new threading the update is down to around 17ms. It's not an incredible gain, but it does make a significant impact on the framerate and the smoothness of the gameplay. While more framerate improvements are planned for the near future, the framerate for the game on the Xbox 360 is finally playable!
The other good news of the week was the load time improvement. Previously I had game objects, animation files, and gameplay data all in separate files per object. I've since consolidated them from over 1100 files down to 3 files. The load time on the Xbox 360 for a full level has gone from over 6 minutes down to around 30 seconds! I'd still like it a little faster, but at the moment it's a great change!
At this point I consider the 360 conversion finished! Cheers and tears! It's time to move back to working on the game itself!
Tuesday, July 15, 2008
- The level allocates an array of 'ManualResetEvents' to signal when a thread is finished working.
- The max worker threads are set to 4 as per this article.
- The object list for the level is in a tree layout. Where a branch starts, a thread (provided it's ready) is set to updating that branch. ThreadPool.QueueUserWorkItem is used to start on the branch updating function.
- The Event array is checked until a new thread is ready. Previously on the PC I was able to use WaitAll and WaitAny but the 360 only supports WaitOne. It's uglier but it seems to work.
While exciting and promising, I've decided to set threading aside for a time and move forward elsewhere with the game. Hopefully some time in the future I can beneficially use threading.
The good news of the week is that I did get a decent framerate boost from switching to a custom shader! Shaders are code that run on individual pixels and vertices. I was previously using the provided BasicEffect shader to draw all my Quads (MBG's advanced sprites). I found this example and was able to spend some time hacking out pieces unneeded. After about a half a day I whittled the shader down to very little, since the game requires no special lighting methods.
The framerate for the PC version boosted around 15% and the 360 version increased about 10%! It was certainly worth the time and makes things look that much smoother.
Tuesday, July 8, 2008
There were a few changes that yielded some large improvements. The first was to 'batch' the processing of the vertices. All of the images of the trees, monsters, etc are created using two triangles stuck together (a 'quad'). While this is like sprites in most games, these quads are slightly more complicated. They are skinned to their vertices in a similar way to a full 3D model in other games; because of this I can't use the built-in SpriteBatch system in XNA. Before the optimization I was simply rendering each quad. With the batching, the quads with the same texture are grouped together in a bigger list. An interesting optimization point is that around 50 quads gives the best results, while a larger list of 200 quads was faster than no batching, but not as fast as 50 quads. There's probably a lot of reasons for this, but NProf suggests that it has to do with spending more time copying the larger vertex buffer needed in the 200 quad version. The framerate jumped to around 15% faster after the batching.
The second change that pushed the framerate even more was the use of DXT compression for the textures. In the Content Pipeline in XNA all textures have an option to use this compression. The interesting thing is the default is 'Color' not DXT (these are in the properties of the texture, under Content Processor, Texture format). I can't visibly tell a difference when using DXT compression, and the framerate increases by about 20% after this!
I found this entry in Shawn Hargreaves' blog very useful for GPU optimization.
The last change I made was to actually shrink the biggest textures used. At their biggest some textures were around 1000x1000. I've shrunk them down to more like 600x600. In my particular case I think it helped supplement the framerate with the previous changes in effect by reducing the texture fetching time.
Currently I'm running into CPU slowdown on the Xbox and am exploring custom shaders for faster drawing and multi-threading for the game object updates. Hopefully these get me the last boost for a great framerate on the Xbox!
Tuesday, July 1, 2008
Last week I finally got Weapon of Choice running on the 360 only to find that it played really slowly and stuttered about. The good news is that I finally have the stuttering under control. It turns out the garbage collection was to blame. For every 1MB I was allocating and leaving to the collector to deal with, it would stall for almost a quarter of a second to clean up. Right now, during a full level, I basically allocate no new memory. It's very nice to see it moving fairly smoothly. For reference I used the CLR Profiler. If you're using XNA, don't use this one.
The bad news is, the game is still slow! Consistently slow, it's true, but still pretty slow. With XNA I have no good performance profiling tools on the Xbox, but I'd guess it's around 10-15 frames a second. That is where the game stands today. Thus I'm currently looking at ways to improve the framerate.
On game sites there's a lot of talk about 60 frames a second. I agree, that's really smooth. I have the game running at a little over 30 frames a second on the PC and it's still smooth and extremely fun. If I can get the game up to 30 fps on the Xbox I'm going to be thrilled. The game would be extremely playable and fun at that framerate.