- renamed the FluidSetting functions to ChangeSetting so that they can be used as a generic means to change music player options without overloading the virtual function table for each minor thing.
- pass Printf as a parameter to the MIDI renderer to uncouple it from the main GZDoom code.
- throw exceptions when setting up the renderer fails so that this can be handled consistently for all construction errors here.
- delete FluidSynth handles before the constructor aborts.
This also removes the OPL dumper because I wasn't able to get any non-broken output from it and have no desire to fix such a niche feature.
# Conflicts:
# src/sound/mididevices/music_opldumper_mididevice.cpp
They were already clean of unwanted external references, but including this file made it hard to keep it that way.
This also moves a few useful definitions around to less 'dirty' headers.
# Conflicts:
# src/rendering/swrenderer/textures/warptexture.cpp
# Conflicts:
# src/doomtype.h
# src/sound/midisources/midisource.cpp
# src/sound/midisources/midisource_smf.cpp
# src/sound/midisources/midisource_xmi.cpp
The organization here is now the same as for the Timidity++ device, i.e. it is the device owning the instruments to give better control over their lifecycle.
# Conflicts:
# src/sound/timidity/instrum_font.cpp
# src/sound/timidity/instrum_sf2.cpp
# src/sound/timidity/mix.cpp
# src/sound/timidity/playmidi.cpp
# src/sound/timidity/resample.cpp
* use std::string instead of FString
* replaced the single use of clamp with std::min/std::max.
* copied MAKE_ID macro into the source.
* use snprintf instead of mysnprintf
* use std::runtime_error instead of I_Error to abort on failed memory allocations.
# Conflicts:
# src/sound/timidity/common.cpp
# Conflicts:
# src/sound/timidity/common.cpp
# src/sound/timidity/instrum.cpp
# src/sound/timidity/instrum_dls.cpp
This is npw a function pointer so that a simple stdout printout can be used as default, but allows to override it.
Also added the missing timidity_file.h header.
# Conflicts:
# src/sound/timiditypp/common.cpp
The only dependency left on the main GZDoom code are the CVars, which will be dealt with next.
# Conflicts:
# src/sound/mididevices/music_timiditypp_mididevice.cpp
The big issues, i.e. FileReader and SoundFontReader still need to be handled to make this a standalone library.
# Conflicts:
# src/sound/timiditypp/configfile.cpp
This is to improve compile times because the MSVC compiler tends to become slow with large lists of source files in a single project.
This new project is still our stripped down copy of libadl, not the original, because that project contains a large amount of baggage we do not need.
# Conflicts:
# src/CMakeLists.txt
# Conflicts:
# src/sound/mididevices/music_adlmidi_mididevice.cpp
Many had leftover non-default constructors/ assignment operators, and some were initialized, even though the initialized data was never used.
In case of FCycler this even caused a default setting to be overwritten when used inside FDynamicLight.
# Conflicts:
# src/g_shared/a_dynlight.cpp
# src/sound/s_sndseq.cpp
Libsndfile cannot decode this format but tries to play these files as regular WAVs and turns them into noise (Both are in a RIFF container.)
# Conflicts:
# src/sound/musicformats/music_xa.cpp
This was solely meant for the original WildMidi player but got seriously in the way of how this code gets used by GZDoom. In GZDoom the player object is owned by the MIDI devive which should be the only instance which is allowed to destroy it.
- Note: Because sound channels are not in zscript, there's no way to modify a sound made by S_Sound.
# Conflicts:
# src/s_sound.cpp
# wadsrc/static/zscript/base.zs
With localization for non-Latin languages on the support list the multibyte API doesn't cut it anymore. It neither can handle system text output outside the local code page nor can an ANSI window receive text input outside its own code page.
Similar problems exist for file names. With the multibyte API it is impossible to handle any file containing characters outside the active local code page.
So as of now, everything that may pass along some Unicode text will use the Unicode API with some text conversion functions. The only places where calls to the multibyte API were left are those where known string literals are passed or where the information is not used for anything but comparing it to other return values from the same API.
# Conflicts:
# src/rendering/hwrenderer/postprocessing/hw_postprocess.h
# src/win32/base_sysfb.cpp
# src/win32/i_main.cpp
# src/win32/win32basevideo.cpp
# src/win32/win32glvideo.cpp
# Conflicts:
# src/version.h
# src/win32/i_main.cpp
# src/win32/i_system.cpp
# src/win32/optwin32.h
# src/win32/win32gliface.cpp
# wadsrc/static/language.enu
