Some really good comments, thanks Ross C :)
I didn't know channels existed. Something for me to investigate!
My code IS a long-winded way of acheiving what it acheives when you consider that the program as it stands is incredibly simplistic and can be acheived with a LOT less code (as you mention).
Following points to consider though: -
1) As much of the 'initialise and load stuff' code is abstracted away from the main source file as is reasonably possible.
2) If I want to load my samples in a different way (unencrypting/unpacking from a .pak file for instance) then I only change sfx.bb and every project that depends on it continues to work without alteration.
3) The sfx_acquire() function will be very easy to base future resource loader functions on (like one for graphics, which is actually the plan).
4) Having an sfx type means that all the information relating to a sound effect is stored exactly where it needs to be.
5) The code pretty much comments itself as to what it is doing (my comments just add the 'why'). This is how it should be in any language but seems hard to do in B3D (compared to C or ASM).
I did consider alternative ways of doing things (just using a load of globals, using a global typeless multidimensional array) but they had such severe drawbacks that I binned them. Using a lod of Globals is just asking for trouble (this was even before I read the thread regarding using Global types instead of bare Globals). Using a multidimensional array (to store panning, volume, 3d positional) results in poorly documented code and a slew of changes throughout the source file if you add a new data element.
If I need to add a 3D positional element to any audio sample (or channel, now I have the idea!) I only need add a new Field to the sfx type and add a little initilisation code to the Read'ing loop.
The project right now is hardly off the ground but what I'm doing is solving scalability problems before they become an issue and start to impact on development of the /proper/ code, the game loop! If everything is modular (as OOP as possible) then seemingly radical design changes later on will not cause a big drama.
One last, possibly irrelevant at this stage, benefit is that the code looks to be quite nicely portable to C++ if ever I decide to go down that road :)
** edit **
The bit where I actually load the wavs in... it looks a bit rough (and I might change it yet) but the idea was to keep the mnemonic references to the sounds (e.g. SFX_BIGEXP) throughout the project. It also enables me to do the extra little sanity check to help ensure the right sound gets allocated to the right constant name (or vice-versa :) ).
I've seen a lot of B3D code that has zero error-checking where resources are loaded. Just because the program continues doesn't mean that it's OK to ignore the error!
I didn't know channels existed. Something for me to investigate!
My code IS a long-winded way of acheiving what it acheives when you consider that the program as it stands is incredibly simplistic and can be acheived with a LOT less code (as you mention).
Following points to consider though: -
1) As much of the 'initialise and load stuff' code is abstracted away from the main source file as is reasonably possible.
2) If I want to load my samples in a different way (unencrypting/unpacking from a .pak file for instance) then I only change sfx.bb and every project that depends on it continues to work without alteration.
3) The sfx_acquire() function will be very easy to base future resource loader functions on (like one for graphics, which is actually the plan).
4) Having an sfx type means that all the information relating to a sound effect is stored exactly where it needs to be.
5) The code pretty much comments itself as to what it is doing (my comments just add the 'why'). This is how it should be in any language but seems hard to do in B3D (compared to C or ASM).
I did consider alternative ways of doing things (just using a load of globals, using a global typeless multidimensional array) but they had such severe drawbacks that I binned them. Using a lod of Globals is just asking for trouble (this was even before I read the thread regarding using Global types instead of bare Globals). Using a multidimensional array (to store panning, volume, 3d positional) results in poorly documented code and a slew of changes throughout the source file if you add a new data element.
If I need to add a 3D positional element to any audio sample (or channel, now I have the idea!) I only need add a new Field to the sfx type and add a little initilisation code to the Read'ing loop.
The project right now is hardly off the ground but what I'm doing is solving scalability problems before they become an issue and start to impact on development of the /proper/ code, the game loop! If everything is modular (as OOP as possible) then seemingly radical design changes later on will not cause a big drama.
One last, possibly irrelevant at this stage, benefit is that the code looks to be quite nicely portable to C++ if ever I decide to go down that road :)
** edit **
The bit where I actually load the wavs in... it looks a bit rough (and I might change it yet) but the idea was to keep the mnemonic references to the sounds (e.g. SFX_BIGEXP) throughout the project. It also enables me to do the extra little sanity check to help ensure the right sound gets allocated to the right constant name (or vice-versa :) ).
I've seen a lot of B3D code that has zero error-checking where resources are loaded. Just because the program continues doesn't mean that it's OK to ignore the error!