Open XaserAcheron opened 2 years ago
libmodplug-1.dll
is needed for tracker music in SDL backend. You can get it from official SDL_Mixer site: https://www.libsdl.org/projects/SDL_mixer/
I recommend setting midi player to portmidi on Windows because the volume does not work properly when playing midi in SDL.
I think all these separate digital music format backends (still called experimental in the code) were back from the dark ages when SDL_Mixer was only able to play back MIDI through its own embedded Timidity library. Well, things have changed a lot since then and with SDL_Mixer versions 2 and up, if configured correctly at build time, you can throw almost everything at it and it will play it back. Sure, it has its own bugs (Windows music volume, support for looping points, etc.), but works pretty much reliable most of the time.
So, for any future development of this port or its forks, I'd suggest to rely and concentrate on SDL_Mixer as the main general music backend with portmidi or @rfomin's winmidi code as a fallback for MIDI on Windows (and keep the OPL emulation, of course). Woof! may be considered as a good example of how this can work.
FWIW, Woof works great out of the box, so doing whatever it does sounds fine to me. :P
I guess from my non-SDL-savvy end user perspective, I was thinking that the other music backends already seem to be doing something to detect that the music lump is a module and pass it to the correct player (DUMB, I think?), but if the code flow for the SDL option is more along the lines of passing it directly to SDL_Mixer and saying "do whatever", then maybe it's less of a mess to just add the new lib and let SDL do its thing.
May want to rename the option to say "preferred music player" instead of "preferred midi player" though, since it's technically affecting more than just .mid playback, though I dunno if there's gonna be many people beyond myself who'd get tripped up by the naming. :P
PrBoom+ viddump feature doesn't work with SDL and portmidi. I think the optimal default would be Fluidsynth with a decent soundfont like GZDoom: https://github.com/coelckers/gzdoom/blob/master/soundfont/gzdoom.sf2 I don't know about the licensing situation with it.
Debian has a very good sounding, small and free default soundfont: https://packages.debian.org/source/unstable/timgm6mb-soundfont
TimGM6mb.sf2 is good but sounds different from Roland SC-55 and MS GS Wavetable. Still better than the current default - the music backend cannot find the soundfont and fallback to OPL2.
Adding the missing dll rfomin linked fixes the problem, so this is just an issue with how the release is packaged. Tested in dsda-doom as well and this fixes the issue.
So, for any future development of this port or its forks, I'd suggest to rely and concentrate on SDL_Mixer as the main general music backend
I've done some testing (https://github.com/kraflab/dsda-doom/pull/91) and unfortunately the cascading hodgepodge of music backends seems to be required in order for the magic of viddump to happen. At least, someone way more knowledgeable than me would be required to make SDL_Mixer render generic audio the way the other backends do for things like ogg and mp3.
Having some partial trouble with module music (.it, .mod, etc.) -- it glitches out and won't play if I set the midi player to SDL (others work fine). Midi player selection ought have any bearing on module playback, so something's fucky.
Quick test wad: https://static.angryscience.net/pub/doom/tests/moduletest.wad -- replaces D_RUNNIN with an .it (Impulse Tracker) module, so load up MAP01 to experience the chaos.
Grabbing a quick snippet of the console output, it seems like it's trying to play back the module with
libmpg123
for some reason, which definitely won't work:I'm running on a build from commit d648724, if it helps -- I see some portmidi fixes in newer commits but nothing that seems directly relevant.