Re: is coding in python easy? just interested
You don't want to throw sounds out unless you have to. The issues that can cause are complex, but basically boil down to hard disk I/O issues. If you want to make a cache, which is the right way, you should look at the weakref module, but don't throw them out when done.
Basically what happens is, everything is fine until it gets to a computer with a slower hard drive or less CPU power. Alternatively, someone tries to make a game that wants to load 10 or 15 sounds at once for *immediate* playback, and the entire thing stalls because the hard drive just can't.
There are 3 solutions to this.
The first is to just load everything at game startup, the beginning of a level, or some other time. This first option works until you or someone using your code gets too big for ram, which almost never happens. The key here is that you don't want to duplicate sounds that are already loaded: you have to make info on where the sound i
s panned separate from the sound itself. If you don't you're looking at each in-game sound from the same file taking as much ram as the size of the file or more if the file was encoded.
The second option when the first becomes too slow is to load all sounds, but use something like the futures module, or some other multithreaded solution. In Python, this isn't complex at all so long as they don't need to share state (they don't). For most games, if they reach this point, it's the third that you actually want and not this one.
The third way is called a cache. It's like your browser cache in most respects, if you're familiar with that. Supposing that you're not handing out sound objects and are referring to sounds by file, the idea is that you load 20 or 30 or 50 and then stop. Pick a number, any number. When the user of the library requests a sound that isn't loaded and the cache is a
s full as you allow, you kill one of the loaded ones and bring in the new one. My preferred strategy for this if I had to give one would be least used gets dropped; other options include least recently used, smallest, largest, etc. One of the things you can do is make cache size based on how much RAM it's using: for a given sampling rate, it's the size of the sample format (2 for 16-bit or 4 for 32-bit) times the sampling rate times the total time of audio in the cache.
But where this last one really shines is this. If sounds are objects and not just one-off events (you want to support this because then you can move it without stopping it playing, among other things), then you can take advantage of the language. Each sound object containing panning info and etc, points at a sound data object. You can keep these data objects in a dict by file name and, when a new sound is requested, look it up there. The magic is that there is a type
of dict in python called the WeakValueDictionary. When nothing else in the program is using the sound data object, it will automatically be removed from the dict. This means that, if the lookup fails, you just load and add a new one. No special code is needed for removal, and the game coder using the library is responsible for, say, not loading 500 hours of audio into ram at once.
But sharing the files behind the scenes and not constantly reloading the files are both very, very important musts.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
