8 Dec 2008

MediaPlayer.Volume causes slowdown

Apologies, this update will be written completely in nerd. Any English-speakers may wish to return again tomorrow.

I discovered today that setting the value of XNA 3.0's MediaPlayer's Volume property on every tick is a bad idea. My game went from running at 60fps to between thirty and four fps in the space of a single build.

I only discovered the above issue after a lot of comparisons with backups, and commenting out changes one by one. I'd lazily decided to update the MediaPlayer's volume once per game update using the latest settings from user preferences, rather than using something sensible like an EventHandler or tracking changes manually.

Quite why setting a float 60 times a second should bring the 360 to its knees is beyond me, especially as it runs Gears Of War 2 fine. I can only assume it's some kind of threading/blocking issue, with the OS thread getting updated a lot less frequently and my program having to wait for it.

Later on, I had more issues with 360 deployment. Pad vibration code that works fine on my laptop refused to work on the 360. I eventually found a workaround, but never sussed the original issue. I'm beginning to wonder how much multi-threadedness is going on with the 360 OS that I'm not aware of; it would seem controller vibration is handled by a separate thread to the program execution.

On the plus side, I was forced into discovering a much quicker way of deploying builds, and the rather useful performance monitor that tells me all sorts of lovely goodness about XNA's garbage collection.

I can nary believe I'm saying it, but I almost wish I was using ClearCase again. Any developer who's worked with it (especially if they're in the CMC Sydney office *cough*) will know it as the work of Satan, but I nearly had a heart attack when I had to track changes the old-fashioned way. Thank goodness for Beyond Compare!

Now, Fallout 3...