Bad Threads and Good Shaders

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 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.
  

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.