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.
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.
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.
This no longer returns a boolean value, but actually returns an
integer indicating the type of OPL chip that was detected. Change
the return value to have a more meaningful value.
Since the addition of OPL3 support, compile of opl_sdl.c generates a
warning because the declaration of Chip__GenerateBlock3() was not added
to dbopl.h.
Previous revamping of the OPL library changed delay times from ms
to us, and switched to 64-bit times for storage for them. However
this type change was botched and some functions were still using
32-bit arguments. Change to 64-bit types.
Thanks Quasar for reporting this. This fixes#438.
Multi-track MIDI files are played back using separate callback chains
for each track, and this introduces the possibility of one track
becoming out of sync with the others. This was noticeable in WADs
that use multi-track MIDIs, such as Alien Vendetta. Increase the
timing resolution to microsecond precision to fix this.
When the tempo is changed, the times on all active timers must be
adjusted to match the new timing values. Add an API to do this and
invoke it when a tempo change meta event is read.
This change rewrites and simplifies the copyright headers at the top
of all source files:
* Remove "Emacs style mode select" line; this line was included in
the headers for the originally released source files and appears
to be to set the file type for old versions of Emacs. I'm not sure
entirely why it was required but I don't think it is any more.
* Remove "You should have received a copy of..." text from copyright
header. This refers to the old 59 Temple Place address where the
FSF headquarters used to be located and is no longer correct.
Rather than change to the new address, just remove the paragraph
as it is superfluous anyway. This fixes#311.
* Remove ---- separator lines so that the file headers are barer
and more simplified.
What support exists is for obsolete devices I no longer possess; I've
never been contacted about the port and it's been several years since
I even bothered to build a new version. All the extra overrides are
clutter that can just be removed.
Subversion-branch: /branches/v2-branch
Subversion-revision: 2615
