The idea is to have more control on the game side instead of dealing with these formats in the backend, which was done for FMod because it already had the decoders implemented.
However, with OpenAL this setup makes no sense and only complicates future extensions that can be better handled at a higher level.
A major part of this device's implementation details about how to handle the callback were not encapsulated by the device class at all, they were #ifdef'd into the streamer class.
This puts everything into the device class which now exposes a clean interface to the rest of the game with no special handling aside from calling two additional virtual functions that are empty for the other devices
* make the critical section local to the respective platform instead of polluting everything with system specific symbols.
* moved system specific class declarations into the source file instead of having them in the global header.
This commit temporarily disables the Windows system device because it cannot be done without polluting the global header and still needs a bit of refactoring.
The approach being used here caused the entire sound system to be infested by windows.h, just to avoid copying around a handful of variables in one place, effectively preventing any compiling optimization.
Windows will now use the same internally defined structure for all MIDI processing which only for actual submission to the system player will be converted to the internal format.
- Replaced GTK/OS X (note different from Cocoa) clipboard code with SDL clipboard API.
- Removed requirement to link to GTK in order to compile with GTK support.
- GTK is no longer init'd if the GTK IWAD picker is not used.
- Our usage of GTK is such that the dynamic loader can work with both GTK2 and GTK3 depending on what's installed.
- Since we're accumulating a lot of library loaders I've built a generic interface as FModule which replaces TOptWin32Proc and the loaders in the OpenAL and Fluidsynth code.
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.
* 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.
Instead of the previous method where there'd be a filename and offset, and/or a
memory pointer, this uses a class to access resource data regardless of its
underlying form.
should ignore any tempo events in XMIDI songs that were left over from the original MIDI
files, since the converter didn't remove them.
SVN r3384 (trunk)
of signaling an event. I would have preferred to use GenerateConsoleCtrlEvent(), but since it
requires the caller be attached to the same console as the process it wants to kill, it's
pretty much worthless. We will continue to look for the presence of the event name in the
TiMidity++ binary despite no longer using it, because standard TiMidity++ builds do not write
to stdout in binary mode on Windows systems.
SVN r2980 (trunk)
degree of support for songs that use loop controllers to loop the song back to a point after
the very beginning of the song.
- Enable loops during SMF generation. Infinite loops will be clamped to some finite amount. (This is currently 30, so a 3 minute song will still restart from the very beginning after 90 minutes)
- Fixed: The SMF, HMI, and XMI readers all generated invalid MEVT_NOP events.
- Fixed: SMF generation died on songs that set their tempo during the initial beat.
SVN r2864 (trunk)
- Added a generic Standard MIDI File creator that works with any of the sequencers. mus2midi.cpp
is no longer used but is kept around as a reference.
SVN r2677 (trunk)
- Moved MIDI precaching logic into MIDIStreamer so that SMF and HMI files can both use the
same implementation.
- Added a player for HMI midi files.
SVN r2675 (trunk)
