A full string match still counts as "starting with". This fixes a bug
with substitute MIDI packs where substitutions were not being loaded
when the full hash was specified.
This allows additional music packs with other filenames beyond the
"well-known" ones. This opens the door for eg. music packs for PWADs
if that's something people want.
This fixes#1051.
Now that this works regardless of the music output type, it's no longer
necessary to hide this behind a conditional widget. So just always show
it.
Part of #440 but will also aid discoverability for music packs
configuration, as part of #1051.
Using Mix_HookMusic() to generate the OPL output stream works fine if
you only ever play OPL music and don't want to use the normal music
output functionality of SDL_mixer. However, now that it's possible to
use substitute music packs with any music output type, this is no longer
the case. Using Mix_HookMusic() disables normal output from eg. Ogg and
FLAC playback. As an alternative, use the post-mix hook and mix the
output from the OPL emulator there.
Cleanup fix as part of #440.
As described in #440, it's counterintuitive that music packs can only
be used if the music device is configured as native MIDI mode. Factor
the music pack part of `i_sdlmusic.c` out into a new file,
`i_musicpack.c`, separating the code that deals specifically with music
packs from the code that deals with MIDIs. This is easily expressible
as a `music_module_t`, doesn't result in a huge amount of duplicated
code, and only requires some minor hooks in `i_sound.c` to support the
overrides.
As an added bonus, the code in both files ends up being significantly
simpler as a result of the refactoring.
This fixes#440 and fixes#528.
We already show a message if substitutions are loaded from a config
file, so show a similar message as well if substitutions are found
based on filenames.
This replaces the widget that controls the music pack path with a
window action button that just opens the configured music pack path.
The path is now automatically created and populated with an
explanatory README file that should explain the purpose to users.
Another major step in implementing #1051.
Currently the user has to create a music pack directory themselves and
configure the path to it in the setup tool. To make configuration
simpler, just create a directory automatically along with a README file
about how to use it, since the user can now just dump files in this
directory.
Part of #1051.
It may be desirable to wrap a window action in a txt_conditional_t
sometimes so that actions dynamically appear based on how the config
changes. So change the TXT_SetWindowAction() API to accept any widget
instead of mandating a txt_window_action_t.
Music packs may be in .flac or .ogg format, so check for both by
using a template with .{ext} where the .flac or .ogg should go. This
also allows the .{ext} syntax to be used in config files.
Part of #1051.
Having a built-in table of common hashes and well-known filenames means
that configuration files will not be necessary in the majority of cases.
This implements most of the functionality of #1051.
Just as with (eg.) Git it's nice to be able to refer to as hash by a
prefix instead of having to type the whole thing, it's convenient to
be able to give a hash prefix in a substitute music configuration.
This change to the internals will also make it simpler to support
a preconfigured table of filenames.
When playing in three window mode it's potentially helpful to have a
borderless mode so that the user can line up three windows next to
each other on a single desktop. However, without the windows borders
it's difficult/impossible to move windows around, so I'm not sure yet
how useful this actually is. It probably depends on the OS.
Thanks to joshthenesnerd for the suggestion.
Doom has always had the ability to load response files containing
extra command line arguments but the command line syntax of
'@filename.rsp' is unpleasant to use on modern Unix shells because
it breaks tab completion. It's actually more convenient to just have
a normal command line argument, so add one.
Some platforms (eg. Emscripten) have their own version of the ar tool,
so it is important to pick one that matches the target architecture.
Without this macro we always use the default system-installed version
of ar.
This prevented either paramater from working properly, since they
would be incorrectly trying to set the other dimension and immediately
switching video modes. Now works like -geometry does.
Resolves#1086
While plain-text versions generally worked, they have been slightly
littered recently with Markdown syntax. We should be able to assume
every Windows user has a web browser and can view these documents
in nicely-formatted HTML pages instead of opening Notepad.
This adds an additional search path when looking for IWADs - in addition
to checking the current working directory, also look in the directory
where the program executable is located.
To give some context for why I'm adding this: apparently there's a small
number of users who do something very unpleasant that I'd really prefer
they didn't: they "install" Chocolate Doom into Steam by replacing
dosbox.exe from their Steam installation of Doom with a renamed version
of `chocolate-doom.exe`. Yuck, I don't approve - it's a grotesque hack.
This works but it has a bug: Chocolate Doom picks up the Steam IWADs
from Windows registry keys. This means that it always starts doom2.wad,
and launching "Ultimate Doom" will actually launch Doom II. This solves
that problem, and while I don't approve of dumb Steam hacks, the change
itself is reasonable and it's an eminently sensible place to look for an
IWAD file.
