- Prefer target properties instead of setting variables whenever possible.
A zmusic-obj target now exists to represent the commonality between zmusic
and zmusiclite.
- Factored out as much as possible from global settings to per target settings
which will make it easier to support using ZMusic as a submodule. Moved
helper functions into a ZUtility.cmake module.
- We now generate and install ZMusicConfig.cmake so find_package(ZMusic)
will work either automatically or given ZMusic_DIR is set.
- CPack is enabled although some refinement is still needed.
- Requires CMake >= 3.13 which is newer than I would normally like, but given
how no one like to refactor these things it may be better to deal with the
short term pain of going a little aggressive on the requirement in order to
avoid having to make things ugly. Especially given that these scripts have
a tendency to be copy/pasted into sister projects. CMake itself has very few
dependencies so users of old Linux distros should be able to easily compile
a supported version of CMake.
- On Windows CMake >= 3.15 is required for redistributable results.
- Cleaned out bits that were copied from GZDoom but not relevant to ZMusic.
Different volume models were means louder or quiter sounding of the rest of notes in the song. And to avoid the mess between volume models, let's use different gain factor for each volume model?
After a small set of tests, it's fine to use the "AUTO" volume model by default.
Every embedded bank and every WOPL file has a setting of a volume model that matches to the behavior of the original OPL2/3 driver of each volume model.
If the same global variable is used by executable that linked to ZMusic dynamic library, both definitions may clash
For example, Linux builds of GZDoom and Raze could crash on exit because of double free, std::string destructor was called twice on the same module_progdir variable
