summaryrefslogtreecommitdiff
path: root/src/midifile.c
diff options
context:
space:
mode:
authorSimon Howard2014-10-14 22:59:42 -0400
committerSimon Howard2014-10-14 22:59:42 -0400
commitc7e82b3866134277e73f9a9d2b0f67da3fa403d0 (patch)
tree512f4f70bdc3516abc5ed0f4d7c1402353c25a24 /src/midifile.c
parent77d7e984d19f52215bf22df95358ef41dda1e430 (diff)
downloadchocolate-doom-c7e82b3866134277e73f9a9d2b0f67da3fa403d0.tar.gz
chocolate-doom-c7e82b3866134277e73f9a9d2b0f67da3fa403d0.tar.bz2
chocolate-doom-c7e82b3866134277e73f9a9d2b0f67da3fa403d0.zip
Fix OPL MIDI tempo calculations.
It turns out that the way that tempo has been calculated in OPL playback has been broken for a long time. The mysterious "fudge factor" that I had to apply to tempo calculations is actually completely unnecessary: the byte-swapping in the MIDI_GetFileTimeDivision() function was being done wrong, so the time division being used by the OPL MIDI code was completely wrong. Presumably the multiply by 260 was close enough to an 8-bit bitshift that it worked okayish, but large enough time division values would overflow a single byte and screw up. This fixes long-running OPL playback problems in a number of WADs, most notably Alien Vendetta. This *really* fixes #352.
Diffstat (limited to 'src/midifile.c')
-rw-r--r--src/midifile.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/src/midifile.c b/src/midifile.c
index 94ec4441..92ffd803 100644
--- a/src/midifile.c
+++ b/src/midifile.c
@@ -699,14 +699,14 @@ int MIDI_GetNextEvent(midi_track_iter_t *iter, midi_event_t **event)
unsigned int MIDI_GetFileTimeDivision(midi_file_t *file)
{
- short result = SHORT(file->header.time_division);
+ short result = SDL_SwapBE16(file->header.time_division);
// Negative time division indicates SMPTE time and must be handled
// differently.
if (result < 0)
{
- // TODO: Figure this out.
- return 96;
+ return (signed int)(-(result/256))
+ * (signed int)(result & 0xFF);
}
else
{