I hate breaking changes. They are like getting into your car and finding that the steering wheel is now the gear lever, and the seats are facing the other way.
Generally speaking the people who make the software try to avoid them too, which is as it should be. But every now and then they make the judgement call that somebody else’s pain is worth their gain, and so they go and move the universe around a bit.
They have done it with the move to XNA 3.1 from XNA 3.0. XNA 3.0 introduced a new SoundEffect type which made it much easier to make sound. Unfortunately, in its original incarnation this type also made it easy to inadvertently make sound that stole all the sound channels by mistake, and so they have fixed this in version 3.1.
Essentially, in XNA 3.0 the SoundEffect.Play() method used to return a reference to a SoundEffectInstance object, that you could then tweak to change some of the properties of the playing sound. This was kind of neat, except that if you ignored the return from Play it meant that the SoundEffectInstance that was created ended up being left hanging around, probably hogging a sound channel, until the garbage man got around to killing it off. If your game was well designed and looked after memory properly this may not happen of course, and so you would run out of sound channels for no good reason.
In XNA 3.1 the same Play method returns something different. It just sends back a boolean value that indicates that the sound is playing correctly. To get hold of a SoundEffectInstace you have to call the aptly named CreateInstance method on your SoundEffect. All very sensible, and much less likely to hog all the sound channels.
However, if you have just written a book which carefully describes the way that XNA 3.0 works in this respect (just like I have) then you are left wondering why they didn’t add an extra method (perhaps called QuickPlay or something) and leave the old Play intact…
Oh well.
