Re: Does holding sounds in memory make sense?
The first time you load a sound, BGT decodes and decrypts the sound as necessary and stores it in memory. If you then create another sound object and load the same sound with it, BGT knows this is what you're doing and so you get a second sound object which simply points to the previously loaded sound. This way you don't reload sounds (ogg vorbis decoding, decryption and disk I/O are heavy duty tasks) and you don't double the amount of memory consumption.
Some ideas for doing this in C++:
Create a class which can store a pointer to some raw memory, the size of that memory buffer and an atomic reference counter.
Use an unordered map which stores references to instances of this object as values and sound file names as keys.
When load is called on a sound object, check to see if the provided filename has already been entered as a key into that dictionary. If it has, pull that instance and point your sound object's reader head at the already prepared audio bytes in that object. Otherwise, load the sound, create the preload object, add it to the map under the sound filename and point your sound object at the newly created data. Either way, atomically increment the preload object's reference counter.
When the sound is closed, decrement the preload object's atomic reference counter. If it reaches 0, remove it from the preload map and destroy it.
In BGT, if you load two different files containing the same audio data (even if they are files with the same name in different locations), BGT loads them separately.
To do otherwise would require hashing or some other means of comparing the two files to insure they are the same, which would negate much of the performance gain earned by doing this in the first place.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
