This is not relevant for any of the stock movies as they use separate sound files, we need to be aware of mods using the streaming sound capabilities of MVE and SMK.
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.
While in GZDoom this uses the IWAD name, the same approach is a lot more problematic here because of name duplications with far more incompatible content.
So this allows targeting a group of base games instead of one specific version.
* 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.
Due to some old code it could happen that these weren't fully set up and missed their translations.
Fixes#301 - Blood's invulnerability palette is identical to the base.
source/build/src/defs.cpp:3198:56: error: cannot pass non-trivial object of type 'FString' to variadic function; expected type from format string was 'char *' [-Wnon-pod-varargs]
To allow cumulative loading without interfering with other ports, Raze will now look for files called xxxx-raze.def, where xxxx is the default .def name (e.g. duke3d-raze.def for Duke3D.) and if that is found, cumulatively load all same-named files - it will fall back on the default name if no such thing is found.
-def still overrides both and will not cumulatively load.
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.
At these places there's some inteference that can bring the engine into an unstable state.
This is not a real fix, just a quick workaround. The actual problem requires closer examination why these are the only places where this happens.
The same logic as in GZDoom applies: The root must not have any other content and the subdirectory must contain identifiable game content.
Some handling was also added to strip out macOS resource fork folders because they can contain data that can confuse file detection.
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.
This was supposed to get the same treatment as d_net.cpp, i.e get the old license restored and be released under a duplicate GPL/Doom Source license but it was somehow missed when it got added. Also removed all leftover Doom specific parts.
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 parser read numbers with leading zeros as octal, which is not wanted here
* texture lookup by file name must be forced for root directory entries.
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.
After discovering yet another misbehaving place in the game I think it can be safely concluded that this is better left off unconditionally.
The only remaining place where this still gets checked is in nnexts, but I wouldn't expect this to work either.
Fixes#292
* Reduce code repetition.
* Clamp incoming horizon when using `settarget()` methods.
* Eliminate double calculation that was occurring in `processhelpers()`.
