How much of a pain in the asssssss would it be to rewrite the next generation of FMOD in a nice cosy OOP way?
I’ve designed sound frameworks before, and in my experience I’v found that implementations like the following are so extremely flexible:
pDevice = AudioMaster->GetDevice(ID_SoundBlasterAudigyOrWhatever);
pStream = AudioMaster->Loader->LoadSource(“monkey.mp3”);
I’ve implemented things like this before, whereby a “device” as such could be a soundcard, or your own custom mixer etc. However I don’t have the time/resources to make it any kind of fully-kitted sound engine.
The most practical benefit of having an OOP FMOD is of course to support multiple soundcards, and as mentioned above, extensive customisability.
[quote="brett":2qln6epy]dont tell anyone i showed you that :P[/quote:2qln6epy]
Nah coz it ain’t like this is a public forum or anything
Although, one thing I must urgently mention is that the framework, while it does indeed look very nice and spanky, doesn’t appear to support multiple devices! You must do this!
And with the possibility of multiple devices, comes the possibilities of custom mixers existing as derived instances of devices! Now that rocks ass…
[quote="brett":3br14ttp]what do you call the ‘System’ object You can create multiple ones of these.[/quote:3br14ttp]
Oooh well that’s ok then
So, if there is one system per device/card, then what class enumerates possible devices? It seems strange to have getNumDrivers() methods etc. if the class they are implemented in only represents one driver…. hmm.
Otherwise, it will definitely be a very sunny day when FMOD 4 comes out.
Please login first to submit.