The current screen job implementation does not coexist well with UI elements.
More like a hotfix, the screen job framework needs to be redone for properly handling input.
* Initial implementation from d32dcd5f8e was not working properly and already had some workarounds for when the player was underwater, etc.
* Re-read implementation in GDX and rebased off of it.
* Fixes#303.
Parts of the sound system treat entry 0 as "no sound" so nothing placed there would play.
This made the one custom sound in "The Way of Ira" not play because as the last sound being defined it ended up in the first, invalid slot.
0 means 'default', -1 means 'silent'. This caused playback issues for useSoundGen. All other places were passing proper volume values along, this is the only one to read the volume from map data.
Blood needs this for its PlayerSound controller, which is run right on map load - so without this it wouldn't start the sound when a map is initiated from the console.
Aside from not having been functional, this is ultimately more harmful than useful as it forces loading of a large number of textures at the same time during gameplay instead of spreading them out.
* made it palette aware
* use backend facilities to track precached data.
* fixes bug in animation precaching loops - they only precached the base index over and over again.
This was incomplete and just ignored Duke's special music, and the levelnum generation used an outdated formula so that it never managed to assign any music to the maps.
This works as long as the loaded mods have one single .ini file in them - in that case it is assumed that it is supposed to replace blood.ini, which will allow dragging & dropping such archives without further user intervention.
Fix undefined behavior/potential OOB access in ST_21_FLOOR_DOOR. g_AnimateGoal does not take a sector number, it takes an animation index, and caps at 1024, not 4096.
The sound system may play sounds on them after their deletion - this resulted in undefined behavior. To ensure properly defined behavior the sprite needs to be retained at least as long as the sound controller may still need it - which cannot be reliably determined so it has to be kept around forever. This would be easier if the sound controller code had proper start and stop events instead of inferring what to do from secondary information.
Fixes#288.
