Cheers Jon!

Nick Gravelyn:Well another run shows I'm still having a bit of Int32s that are being allocated onto the heap, but this time it shows them all stemming from DateTime.Now. Any ideas if that's just a mistake of the CLRProfiler or is the DateTime.Now property actually generating garbage? I looked at it in Reflector, but I didn't see anything ...

I think the only way to do this is to create an instance or global variable in XACT, bind it to the ''pitch'' of the sound you're playing, then set the variable in code using Cue.SetVariable(string name, float value);If you only want to change the speed and not the pitch, you might run out of luck here - there aren't any tempo change filters for ...

It looks rather like the SpriteBatch's texture filtering is causing the issue.  Take for example the bit where you draw the top - you're taking a 1x10 area of the sprite and drawing it across a 180x10 area of screen.  By default the texture unit will bilinearly filter the texture which will interpolate the texel at (50, 0) with the texel ...

I'm not sure when the static constructors run, but is it possible to move the construction into a more explicit place, and run it explicitly from the main thread before the secondary thread starts up?  It's feasible (though I would have thought unlikely) the runtime lazily runs the static constructors, in which case unless the lazy ...

How does the status ''Closed (External)'' fit into that?  Cheers :)

This sounds like a run-time error, not a compile error.  In XACT, have you created a cue called ''FF6_Battle''.  XACT can be a little confusing, if you just add a wave file to it, you then need to drag that wave file into a sound bank, then create a cue for that sound, and name it ''FF6_Battle''Also, it looks like you have a trailing ...

Hi Shawn,I've been able to replicate this issue in a very small test bed (in the in testbed, the GC doesn't seem to run, but the music still cuts out).  What's the best way to get this replicable case to you guys?  I can make a Connect bug and attach a file but it'll be pretty darned huge (plus copyright issues etc).  Feasibly this ...

That's exactly right -- the object is constructed separately to any graphics behaviour, so there's not necessarily a valid GraphicsDevice around during construction.  LoadGraphicsContent is the correct place to put anything that caches the GraphicsDevice.  This has the side effect of automatically handling cases where the GraphicsDevice ...

Righto Shawn, thanks for that -- you got my hopes up!  For now looks like I'll have to fall back on magic naming conventions of the Techniques themselves.  Cheers :)