The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
- Converted P_MovePlayer and all associated variables to floating point because this wasn't working well with a mixture between float and fixed.
Like the angle commit this has just been patched up to compile, the bulk of work is yet to be done.
- Worked aorund modern GCC bug where C++ exceptions in Objective-C++ code would result in an ICE (bug is already on their tracker, but I doubt it will be fixed unless I decide to dig into the issue myself).
- Turn off fused floating point instructions since these can cause slight deviations in floating point code.
- Use -static-libgcc when compiling on the Mac with GCC since we need to use a custom version of GCC to do so now.
- Note: ZDoom will currently still crash on exit on PowerPC since it seems to be deciding that NameManager needs to be destructed before the console commands.
OpenAL specification doesn't require alcGetIntegerv() to return meaningful values for ALC_MONO_SOURCES and ALC_MONO_SOURCES.
At least Apple's OpenAL implementation returns zeroes, although it can generate reasonable number of sources.
This cuts down on as much message noise as possible, outputs everything to a file specified as a parameter and then quits immediately, allowing this to run from a batch that's supposed to check a larger list of files for errors.
Multiple outputs get appended if the file already exists.
The reason for this is that on my system, the static or delay loaded method always picks the (obsolete) system-installed OpenAL version (needed for some old games) which is not wanted here if there's another one in the local ZDoom directory.
This also removes the dependency on the broken import library that comes with OpenAL Soft which causes compile errors with more modern MSVC compilers on default settings.
- Looking over the code again, I see that discarded SysEx messages can
cause the same issue as unhandled meta events, so generalize the
returning of a NOP for everything.
* OPL: specify the core to use for playing this song
* FluidSynth: specify a soundfont that should be used for playing the song.
* WildMidi: specify a config file that should be used for playing the song.
* Timidity++: specify an executable that should be used for playing the song. At least under Windows this allows using Timidity++ with different configs if the executable and each single config are placed in different directories.
* GUS: currently not operational, but should later also specify the config. This will need some work, because right now this is initialized only when the sound system is initialized.
* all other: no function.
These options should mainly be for end users who want to fine-tune how to play the music.
- increased the valid range of patch values for MUS. According to the original MIDI2MUS code it can handle numbers up to 188, not 181, and at least one track from Eternal Doom uses #183.
According to blzut3, it looks like it is a byte followed by a variable length field. It can be any value 0-15 and will be followed by that many bytes one for each bank used. If the bank count is 0 then it is shorthand for using one bank (bank 0).
Based on evidence from several songs in Eternal Doom the description in all known documents is wrong. The instruments are not stored in a 16-bit word but in an 8-bit byte, followed by some variable size data.
Known variations are:
* second byte is 0 - no additional data follows
* second byte is 1 - a third byte for the 'bank' value follows.
