Doomworld is now available over https: so there's no reason to link
to unencrypted http: URLs (which are just redirect anyway). Also the
idgames interface URLs have changed.
I think these were introduced when functions in the file were made
static, eg.
"static declaration of 'OPL3_EnvelopeGenOff' follows non-static declaration"
Make function prototypes static where appropriate.
If the savegame directory is unwriteable we should exit with an error -
the previous behavior caused an infinite loop of attempting to open the
same file repeatedly. Because the player may value the progress they
have made, attempt to write the savegame to a temporary directory first
before exiting with an error.
This fixes#659. Thanks to @terrorcide for the bug report.
We only initialize the joystick subsystem if usejoystick is true, but
joystick_index must also be valid in order to use a joystick, and a
negative value indicates no joystick is set.
Versions of make other than GNU make don't support automatic variables
in explicit rules, only in suffix (implicit) ones.
This fixes the build on FreeBSD (and possibly other BSD variants), which
was failing with errors like:
cp chocolate-doom-setup
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpvx] source_file target_file
cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpvx] source_file ... target_directory
*** Error code 64
Stop.
The server was rejecting connects when running with chex.wad, because it
was expecting the gamemode to be shareware; in fact, chex.wad contains
four episodes worth of levels (even though only five levels are used).
Technically it is therefore a retail IWAD and we should expect
gamemode=retail when using it. This fixes#647; thanks to Danfun64 for
reporting the bug.
The use of I/O ports in the Linux driver to directly control OPL chips
is x86 specific and only really makes sense for x86-based PC's with
compatible hardware.
For some architectures (e.g. ARM), ioperm, inb and outb do exist and are
detected by the configure script (via AC_CHECK_FUNCS(ioperm)), but their
use is inappropriate in these cases and should be avoided.
In some other scenarios, like when using a GNU toolchain + uClibc for
PowerPC, the build even fails with the following error:
opl_linux.c:26:20: fatal error: sys/io.h: No such file or directory
That is so because ioperm() is exported by uClibc and gets detected by
configure, which enables the "Linux" driver via definition of
HAVE_IOPERM, but in practice 'sys/io.h' is missing for ppc (inb/outb is
not implemented, and the call to ioperm() would return EIO anyway).
So, besides testing for HAVE_IOPERM, also test if either __i386__ or
__x86_64__ are defined before enabling this OPL driver.
