Mommy's Best Games, Inc. is an independent game developer founded in 2007. Our seventh game, currently in development, is Pig Eat Ball on which we started working in 2013. This is behind the scenes thoughts about game development and marketing.

Thursday, July 24, 2008

I've tried four versions of threading at this point and finally have a noticeable speed up in the game. The original version was using the .NET threadpools. I've found out those weren't meant to be used in a situation that required high performance. Then I tried an implementation of my own design that resulted in a slower framerate. Then I got a little help from an old friend which resulted in a threading solution that worked, but the framerate stayed about the same.

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

In an effort to better use the Xbox 360 I've been looking into multi-threading the update loop in the game. After waffling between a custom managed thread system and the .NET ThreadPool, I settled on the ThreadPool. It seemed to make sense on the PC. I have it arranged basically as follows:

The level allocates an array of 'ManualResetEvents' to signal when a thread is finished working.

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.

When I finally ported it to the 360, it turned out that the pool was allocating lots of various objects during runtime down inside the .NET functions. As we saw before this causes the 360 to collect garbage which slows everything down.

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

I'm happy to report the framerate for Weapon of Choice on the Xbox 360 is playable! It's still not 'great' but it is 'okay'. I know that's not the best report but when the framerate made the game unenjoyable just a week ago, I'm feeling pretty good about it. And on a decent computer, the framerate is smoking (often around 80 fps)!

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

Weapon of Choice is programmed using Microsoft's .NET framework and is programmed in C#. This means unlike the C programming language, in which memory is deallocated manually, 'garbage collection' takes care of cleaning up memory. The difficult thing about it is while it's nice to have something handle this automatically, the Xbox 360 version of this garbage collection is really slow compared to the PC.

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.