Doom DOS vs Doom PS1

[Chilly Willy]

Jaguar Doom's music is just plain weird.

The Jaguar cannot play instruments from the rom, so they have VERY limited ram for instruments. Because of that, wavetable instruments are small and limited in number. Whenever they can, they use FM synth instruments... but those instruments are NOT done in hardware, they're done in software by the sound risc processor! The combination of small/limited wavetable instruments with software FM synth instruments is what makes Jaguar music sound "weird". The musician for the game has to take that into consideration while doing the music, much the same as Genesis musicians have to take into account the YM2612/PSG.

Contrary to that, the 32X can play instruments from rom as long as they are not compressed. My MOD player uses uncompressed MODs in rom, including the embedded instruments. They are not copied to ram as there's not enough ram for that, but fetched straight from rom. This increases bus contention, but as my Yeti3D+MOD demo shows, it's not enough contention to slow the game noticeably. A 32 channel XM would probably show significant bus contention, though.

[kool kitty89]

ANYTHING is better than the 32X version's horrible excuse for OPN2 FM Synthesis. Couldn't the development team have at least put a little bit of time to ATTEMPT to replicate the OPL3 soundtrack from the DOS version?

Given that GEMS was used, and assuming the composer/programmer wasn't skilled in making custom FM patches (but was still a reasonably capable mulsical composer), the best option would have been to remix the soundtrack to cater as well as possible to the default GEMS instruments (preferably adding in some PCM/PWM percussion too).

A better case would be a composer/programmer well-versed in using FM synth and making their own patches (as seen with better GEMS compositions), though that still shouldn't involve trying to mimic OPL2/OPL3, but remixed to better fit the OPN2 along with some limited use of samples (and possibly PSG).

I'd still take the Super NES version simply because the 3DO version looks like it can crash at any time and just feels more clunky than the Super NES version. It's just really bad.

Even with the 3DO version set to the smallest screen size? (which is rather similar to the SNES's resolution . . . they really should have used low detail on the 3DO version by default, maybe even offered a 1/4 resolution mode that halved vertical resolution too -though that doesn't give as big of a speed boost as cutting rays out, it still cuts rendering time- so you could have 160x96 stretched to full-screen -especially with the 3DO's interpolation enabled- and have the status bar rendered separately at full res; after all, people seem to think Chilly Willy's 160x112 yeti 3D)

Imagine if the 32x version was stuck in high-detail mode.

The Jaguar cannot play instruments from the rom, so they have VERY limited ram for instruments. Because of that, wavetable instruments are small and limited in number. Whenever they can, they use FM synth instruments... but those instruments are NOT done in hardware, they're done in software by the sound risc processor! The combination of small/limited wavetable instruments with software FM synth instruments is what makes Jaguar music sound "weird". The musician for the game has to take that into consideration while doing the music, much the same as Genesis musicians have to take into account the YM2612/PSG.

Contrary to that, the 32X can play instruments from rom as long as they are not compressed. My MOD player uses uncompressed MODs in rom, including the embedded instruments. They are not copied to ram as there's not enough ram for that, but fetched straight from rom. This increases bus contention, but as my Yeti3D+MOD demo shows, it's not enough contention to slow the game noticeably. A 32 channel XM would probably show significant bus contention, though.

Actually, that's not true . . . the Jaguar can have the DSP fetch samples from ROM, decompress them (if compressed), and mix to a buffer in the 8k scratchpad (or to main memory, but the DSP has bugs that make main accesses slow in general, so best to avoid that -especially writes, reads aren't as bad).
You could also read from main RAM rather than ROM, and that would be considerably faster though slower than the normal DRAM bandwidth due to DSP bugs. (it takes 6 cycles to read a 16-bit word vs 2 -in FPM- or 5 -with a page change- compared to 10 cycles in the commonly used 375 ns ROM; writes to main memory take 12 cycles rather than 6, so you'd especially want to avoid that)

The 8 kB DSP scratchpad is intended to limited buffering and fast code only (somewhat like the Z80's work RAM in the MD -or more like an SH2 with the entire cache used as a scratchpad), it's not meant for storing whole samples at all. (there's also a 4k wave ROM intended for wavetable, additive, subtractive, FM, etc types of sound synthesis independent of external memory).

There's no DMA sound or even FIFO buffering in the Jaguar, the DSP must play any samples (or any synthesized sounds) with precise timing to the DACs. This isn't a major problem since the DSP (and GPU) RISCs are extremely efficient with interrupts, so simply using interval timer interrupt routines work quite well. (the J-RISCs allow registers to be set aside specifically for interrupts, so time isn't wasted saving tons of registers -especially important since there are a copious 64 32-bit general purpose registers in each RISC chip)
So doing 44.1 kHz stereo interrupt driven PCM is a non-issue for the Jaguar's DSP. (Crazyace also mentioned that ARM and MIPS have special fast IRQ modes too)
Does the SH-2 have any special fast interrupt modes?


Atari had support for Amiga formatted MOD players and an 8-channel sample based MIDI driver, and I believe it's the latter which Doom uses. The problem is that the driver ended up using too much bandwidth (or too much DSP time in general -assuming Carmak had the DSP handling things other than audio), so the game became choppy with music enabled and they ran out of time to further optimize it.

[Chilly Willy]

Actually, that's not true . . . the Jaguar can have the DSP fetch samples from ROM, decompress them (if compressed), and mix to a buffer in the 8k scratchpad (or to main memory, but the DSP has bugs that make main accesses slow in general, so best to avoid that -especially writes, reads aren't as bad).

Well, yes, it's LITERALLY possible, but you'd be an idiot to do it. The Jaguar source I've seen (remember I bought that DVD of Jaguar source) plays all instruments from DSP ram. Wavetable samples are loaded when the music is initialized, and FM instruments are setup. I would imagine that only long, one-shot sound effects are played from rom or main ram.

There's no DMA sound or even FIFO buffering in the Jaguar, the DSP must play any samples (or any synthesized sounds) with precise timing to the DACs. This isn't a major problem since the DSP (and GPU) RISCs are extremely efficient with interrupts, so simply using interval timer interrupt routines work quite well. (the J-RISCs allow registers to be set aside specifically for interrupts, so time isn't wasted saving tons of registers -especially important since there are a copious 64 32-bit general purpose registers in each RISC chip)
So doing 44.1 kHz stereo interrupt driven PCM is a non-issue for the Jaguar's DSP. (Crazyace also mentioned that ARM and MIPS have special fast IRQ modes too)

Yeah, you can see that in the DSP code for the music/sound player. It's like running the 32X PWM in interrupt mode. Maybe that's why all the 32X games do that - they were used to doing that for Jaguar games.

Does the SH-2 have any special fast interrupt modes?

The SH2 uses vectors for interrupts on the 32X. An interrupt occurs, the SH2 saves SR and PC to the stack, fetches the vector for the interrupt from SDRAM, the jumps to that address. It's pretty fast - SH2 module ints are 7 cycles + the bus cycles needed to save SR and PC and read the vector; external interrupts are 10 cycles + the bus cycles needed to save SR/PC and read the vector.

Because of a bug in the developer units, SEGA had the developers use a "unified" interrupt handler - all interrupts point to the same vector, and the handler determines which interrupt occured by looking at the interrupt level. That made calling a specific int handler slower, but not much slower... you lost more time saving and restoring registers than in dispatching the handler.

Atari had support for Amiga formatted MOD players and an 8-channel sample based MIDI driver, and I believe it's the latter which Doom uses. The problem is that the driver ended up using too much bandwidth (or too much DSP time in general -assuming Carmak had the DSP handling things other than audio), so the game became choppy with music enabled and they ran out of time to further optimize it.

The music player I've seen used in the code disc looks like a modified MIDI/MUS player, allowing up to 32 instruments. Here's some info I derived on the player from Rayman (it used in other games too, but I was more interested in the Rayman music):

The table of tracks is at offset $1210F0 in the rom. Each entry is 4 LONG values (in big endian format... everything in the Jaguar is big endian). The first LONG is a track global volume as a WORD, followed by a flag (either FFFF or FF05); the second is a pointer to the compressed track score (AND with $3FFFFF to get the offset in the rom); the third is a bitmask of envelops used by the track, and the fourth is a bitmask of waveforms used by the track. A bit set for an envelope without a corresponding waveform bit set indicates an FM instrument as opposed to a wavetable instrument. A track score pointer of 0 indicates the end of the table.

Track scores are compressed using Rob Northen Compression mode 2. They consist of a number of pairs of LONG values. The first LONG is the time you should wait for before processing the second LONG in the pair. The time is incremented by timer 2 at the tempo rate of the song. It's not a relative delay, it's an absolute time. The second LONG is the score event. One field is the voice number - if the voice is currently off, the event is always a note on event with the following form:

b31-29 = unused
b28-26 = voice #
b25-21 = patch # (instrument to play on this voice)
b20-07 = pitch
b06-00 = volume (0 to 127)

There are only 29 instruments used by Rayman; they are in order: acoustic bass, clarinet, kick drum 2, open hihat, electric snare 2, fretless bass, electric piano 1, closed hihat 2, percussive organ, acoustic nylon guitar, rock organ, a custom fm instrument, kalimba, contrabass, synth pad 2, harmonica, oboe, pizzicato strings, distortion guitar, synth brass 1, acoustic grand piano, vibraphone (or is it a vibra slap?), cello, soprano sax, percussive conga (not sure about this?), sitar, xylophone, melodic toms, and some instrument called a hulotte (no idea - but it's French for a tufted owl). No bits are set in the bitmasks for bit 29 to 31, so those are unused.

If a voice is on, the event has a different form:

b31-29 = event, 0 = note off, 1 = pitch change, 2 = change controller, 3 = jump, 4 = pitch change, 5 to 7 unused

For everything but jump, the following fields are defined:

b28-26 = voice
b25-21 = patch #
b20 = flag, 1 = modify value in patch table, 0 = modify value in voice
b19-15 = controller # (for change controller, defined controls are 7 = volume, 9 = pitch bend, 10 = pan)
b14-00 = value (volume, pitch, or pan depending on the event)

Note that there are three ways defined to set the pitch... they all do the same thing. So far that I've seen, the way the pitch is set is using event 4.

For jump, the following fields are defined:

b28-08 = signed offset of jump divided by 8; multiply value by 8 and add to current pointer to get the jump address
b07-00 = count; if b7 is set, ignore the count and always jump; if b7 is not set, skip jump if 0, otherwise decrement b6-0 and do jump

The time is reset to the time for the target address of the jump (the first long).

Note that the count isn't very useful as you'd have to reload the count when replaying the music. None of the tracks I've examined so far use the count - they set b7 so that it always jumps... in fact, it's always the last event in the score - jump back to the very beginning of the score.

[kool kitty89]

Well, yes, it's LITERALLY possible, but you'd be an idiot to do it. The Jaguar source I've seen (remember I bought that DVD of Jaguar source) plays all instruments from DSP ram. Wavetable samples are loaded when the music is initialized, and FM instruments are setup. I would imagine that only long, one-shot sound effects are played from rom or main ram.

That doesn't sound right . . . many games used instrument samples that sound way too long to fit into the 8k DSP SRAM (let alone buffered along with other samples). Unless you just mean that samples are partially buffered into SRAM (ie paged) and then mixed and output to another buffer to be read out to the DACs. (that would seem like unnecessary overhead though, compared to just reading from RAM -or ROM- and writing to a buffer in SRAM -and decompressing prior to that if compression was used)

The only practical way to avoid significant use of external memory would be to use sythesis methods other than sampling. (ie additive, subtractive, wavetable -true wavetable that is, granular, FM, or some combination thereof) There's a small wave table ROM with a selection of simple waveforms to help with such synthesis methods in addition to scratchpad RAM -which could obviously hold some additional wave samples. (it includes tirnagle, sine, amplitude modulated sine, sine+2nd order harmonic, "chrip" -sine with increasing frequency, triangle+noise superimposed, spike, and white noise)
There was an FM synth driver included in the development kit.

Or did you literally mean true wavetable samples (for wavetable synth -like an ensoniq chip, not sample synth) when you say "wavetable samples loaded" into RAM. (in that case, yes, it would be sensible since you would be synthesizing sounds algorithmically using various small wavetable samples)

The MOD player examples on the system would obviously not be using the wavetable (or FM, etc) method though.

The SH2 uses vectors for interrupts on the 32X. An interrupt occurs, the SH2 saves SR and PC to the stack, fetches the vector for the interrupt from SDRAM, the jumps to that address. It's pretty fast - SH2 module ints are 7 cycles + the bus cycles needed to save SR and PC and read the vector; external interrupts are 10 cycles + the bus cycles needed to save SR/PC and read the vector.

But does SH2 allow fast interrupts that only reserve a limited number of registers for interrupts as crazyace mentioned the Jag-RISC (and similar examples in ARM and MIPS) can do?
as mentioned here:
http://www.sega-16.com/forum/showthr...l=1#post371930
You answered your own question - ( you wouldn't need to reserve all of the registers ), interupt response is fast on the DSP.
Also with 44.1Khz you have nearly 600 cycles between interupts - so plenty of time to prepare the next output sample.
http://www.sega-16.com/forum/showthr...l=1#post372279
Yes - You also have something similar (FASTIRQ) on ARM , and MIPS had very low latency IRQ's ( at the cost of always reserving 2 registers k0/k1 )

The music player I've seen used in the code disc looks like a modified MIDI/MUS player, allowing up to 32 instruments. Here's some info I derived on the player from Rayman (it used in other games too, but I was more interested in the Rayman music):

From what crazyace mentioned, many developers used their own sound drivers, but Atari did have one available in the SDK as well, as he described here:
http://www.sega-16.com/forum/showthr...l=1#post371930
Atari had a 8 channel music player ( + extra channels for sound fx ) that supported FM synth , Wavetable, and compressed samples - it was MIDI based. Other dev's rolled their own. ( Atari's source was in the SDK )


The question would be which games used that engine vs 3rd party alternatives.


If Doom did all music via non-sample based synthesis methods (ie wavetable, FM, etc -definitely doesn't sound like FM, might be wavetable though), then DSP memory bandwidth would definitely not be a problem . . . which would mean that the DSP is overloaded by other computational duties to properly handle the music player.

[Chilly Willy]

That doesn't sound right . . . many games used instrument samples that sound way too long to fit into the 8k DSP SRAM (let alone buffered along with other samples). Unless you just mean that samples are partially buffered into SRAM (ie paged) and then mixed and output to another buffer to be read out to the DACs. (that would seem like unnecessary overhead though, compared to just reading from RAM -or ROM- and writing to a buffer in SRAM -and decompressing prior to that if compression was used)

The only practical way to avoid significant use of external memory would be to use sythesis methods other than sampling. (ie additive, subtractive, wavetable -true wavetable that is, granular, FM, or some combination thereof) There's a small wave table ROM with a selection of simple waveforms to help with such synthesis methods in addition to scratchpad RAM -which could obviously hold some additional wave samples. (it includes tirnagle, sine, amplitude modulated sine, sine+2nd order harmonic, "chrip" -sine with increasing frequency, triangle+noise superimposed, spike, and white noise)
There was an FM synth driver included in the development kit.

Or did you literally mean true wavetable samples (for wavetable synth -like an ensoniq chip, not sample synth) when you say "wavetable samples loaded" into RAM. (in that case, yes, it would be sensible since you would be synthesizing sounds algorithmically using various small wavetable samples)

The MOD player examples on the system would obviously not be using the wavetable (or FM, etc) method though.

Well, I'm hardly the Jaguar expert here, so maybe I'm mistaken on that point (copying wavetable samples to ram). Let's look at the DSP init...

; DSP START +++++ DONE JUST ONCE

; Put big-endian mode and init stop DSP flag

; Setup clock synchronous serial clock

; Copy instruments env table from ROM to RAM Init env labels in MUS_envDSP

; First we copy the Jerry code into Jerry ($F1B000)

; Now we copy the tables into Jerry Don't touch a1

; Save the adress of free DSP ram to use next

; Set the volume

; Disable all interrupts except CPU int (others permitted by DSP code)

; Good flags for DSP starting

; Enable sound (mute bit)

; SYNTH START +++++ DONE EACH TIME A NEW MUSIC STARTS

; Get free DSP ram adress previously saved

; Here we decompress the score according to the level

; Tell the music driver where the music score is located.

; Now let's set up a patch table next, in memory, to the score table

; Reset env table to do the next copy of envs in DSP ram

; Prepare the access of the music MUS_number in MUS_table to copy right
; env and right waveform to the DSP ram.....

; Now we copy some enveloppes to DSP Ram

; Looking each instrument to see if it is a FM, if it is, take the right
; enveloppe and copy it in the DSP Ram, if several inst. use the same
; enveloppe, the copy is done only one time. Pointers to enveloppe are
; put to new adresses

; Now we copy a waveform to DSP Ram on 512 bytes boundary

(here is a routine that copies all the wavetable samples ending with this line)

move.l a6,MUS_free ; Free DSP RAM (D_ENDRAM - MUS_samples)

; Now we copy some samples to DSP Ram (optimized for each score)

; Set the volume according to the music number

; Permits sound effects to be played ................

; Set up JPIT1 (timer)

And it goes on... but it sure LOOKS like it copies the wavetable samples to DSP ram, along with some "samples".

But does SH2 allow fast interrupts that only reserve a limited number of registers for interrupts as crazyace mentioned the Jag-RISC (and similar examples in ARM and MIPS) can do?

No. It doesn't do that. It's just like the 68000 - save the sr, save the pc, fetch the vector, jump to the vector. The handler must save and restore any registers it uses and then do a rte instruction.

From what crazyace mentioned, many developers used their own sound drivers, but Atari did have one available in the SDK as well, as he described here:
http://www.sega-16.com/forum/showthr...l=1#post371930
Atari had a 8 channel music player ( + extra channels for sound fx ) that supported FM synth , Wavetable, and compressed samples - it was MIDI based. Other dev's rolled their own. ( Atari's source was in the SDK )

That seems to be the one I'm commenting on.

The question would be which games used that engine vs 3rd party alternatives.


If Doom did all music via non-sample based synthesis methods (ie wavetable, FM, etc -definitely doesn't sound like FM, might be wavetable though), then DSP memory bandwidth would definitely not be a problem . . . which would mean that the DSP is overloaded by other computational duties to properly handle the music player.

Maybe that's why Doom couldn't play music during the game (on the Jag) - it was playing instruments from rom instead of DSP ram. That would certainly give bad bus contention on the Jaguar. Looking at the Doom music code, it definitely is using its own player, not the "standard". It looks like it copies the data from the current channel at the current rate to scratch ram for mixing. Sure looks like it's pulling from the rom.

[kool kitty89]

Well, I'm hardly the Jaguar expert here, so maybe I'm mistaken on that point (copying wavetable samples to ram). Let's look at the DSP init...

; DSP START +++++ DONE JUST ONCE

; Put big-endian mode and init stop DSP flag

; Setup clock synchronous serial clock

; Copy instruments env table from ROM to RAM Init env labels in MUS_envDSP

; First we copy the Jerry code into Jerry ($F1B000)

; Now we copy the tables into Jerry Don't touch a1

; Save the adress of free DSP ram to use next

; Set the volume

; Disable all interrupts except CPU int (others permitted by DSP code)

; Good flags for DSP starting

; Enable sound (mute bit)

; SYNTH START +++++ DONE EACH TIME A NEW MUSIC STARTS

; Get free DSP ram adress previously saved

; Here we decompress the score according to the level

; Tell the music driver where the music score is located.

; Now let's set up a patch table next, in memory, to the score table

; Reset env table to do the next copy of envs in DSP ram

; Prepare the access of the music MUS_number in MUS_table to copy right
; env and right waveform to the DSP ram.....

; Now we copy some enveloppes to DSP Ram

; Looking each instrument to see if it is a FM, if it is, take the right
; enveloppe and copy it in the DSP Ram, if several inst. use the same
; enveloppe, the copy is done only one time. Pointers to enveloppe are
; put to new adresses

; Now we copy a waveform to DSP Ram on 512 bytes boundary

(here is a routine that copies all the wavetable samples ending with this line)

move.l a6,MUS_free ; Free DSP RAM (D_ENDRAM - MUS_samples)

; Now we copy some samples to DSP Ram (optimized for each score)

; Set the volume according to the music number

; Permits sound effects to be played ................

; Set up JPIT1 (timer)

And it goes on... but it sure LOOKS like it copies the wavetable samples to DSP ram, along with some "samples".

OK, so we're talking wavetable synthesis type samples (really tiny wave samples), not long samples of SNES/Amiga MOD/GUS/etc/etc type sampled synth. (plus support for FM instruments or other realtime synthesis methods)

Atari's driver seems to have support for normal sample synth (and sample playback for SFX, including compressed samples), but in addition to the variety of other synthesis methods. (and that's what the many MOD-player or MOD-like tracks seem to use . . . or their own drivers doing simple PCM/ADPCM based sample synth -Checkered Flag definitely sounds like MOD, though I suppose wavetable synth can be misleading . . . the fact that it has hard L/R oriented channels -a la Amiga- seems rather suspicious though -something several PC mod players did as well when using the STe, SB Pro or SB16, in spite of full stereo panning being about as intensive as fixed L/R channels)

I'd gotten the impression that a lot of Jag games did use simple sample based MOD players for sound, but maybe I've gotten the wrong idea and most games actually did use realtime synth of some sort. (albeit some seem to have used relatively simple synth sounds -like the pseudo-analog style synth of Raiden, very heavy use of pulse waves)

Maybe that's why Doom couldn't play music during the game (on the Jag) - it was playing instruments from rom instead of DSP ram. That would certainly give bad bus contention on the Jaguar. Looking at the Doom music code, it definitely is using its own player, not the "standard". It looks like it copies the data from the current channel at the current rate to scratch ram for mixing. Sure looks like it's pulling from the rom.

If that really is the issue, that would mean other games that used MOD players or similar sample drivers (assuming they DID do that) would also be hurting the system significantly.

However, a basic 8-channel sample playback engine really shouldn't take up that much bandwidth, even under a worst case scenario . . . unless you're using something like odd uncompressed samples at high sample rates. (the DSP saturates the bus at 8.87 MB/s in DRAM or 5.32 MB in ROM -assuming 375 ns ROM, so something like an 8 channel sample player using 11 kHz 4-bit ADPCM samples -interpolated to 44 kHz- would take less than 1% of the bandwidth if reading from ROM, perhaps 1% with a couple SFX channels added in . . . or a bit more of the samples were read at more than 11 kHz for sampling to the highest pitches)
Even in a bad case, using plain 8-bit PCM (or ulaw) or higher quality ADPCM samples, it probably shouldn't go over ~5% of the bandwidth for doing an 8 channel music player (with 1 or 2 SFX channels).
Maybe trying to do something like a 24-32 channel player would screw the bus though, or there's some cases where 3-5% bandwidth could still be a major issue.

But yes, in terms of bandwidth (for cases where the DSP is not needed for other coprocessing), a good realtime wavetable/FM/etc synth driver would be preferable. (and those methods really can result in nice music, especially with a composer/programmer experienced with those types of synth) Not to mention it makes much more efficient use of ROM space. (heh, would have been interesting if one of the 4th gen consoles had used an ensoniq-type synth chip . . . albeit Atari had actually planned that for the Panther, and the Apple IIgs used one too)

On another note, DSP bandwidth was also a problem with CD audio on the Jag CD. For some reason, they decided to mix CD audio digitally via the cart bus to the DSP (at least that's my understanding), thus requiring 176.4 kB/s of main bus bandwidth through the cart slot. (so at least 2% of main bus bandwidth, or worse if the cart bus has speed restrictions -I forget whether that 375 ns rate is fixed or not, it would make more sense to be variable to accommodate faster ROMs as prices fell, or other things interfacing through the cart slot)

[Orchid87]

I can't see myself playing Doom with either that or Roland Virtual Sound Canvas as they just sound WAY too different from a real Sound Canvas.

Yeah, VSC sounds different from real SC card but it's still miles better than Doom music in OPL mode.

[Bastardcat]

Good old SB-16 for me. That's how I like my Doom music. Not the highest quality, but I love it just the same.

[Ace]

Have you tried playing the DOS version of Doom with the set dmxoption=-opl3 option? This improves the music when using FM Synthesis as it makes use of OPL3's extra channels and stereo panning. The only thing I don't get is why the Stereo is backwards when using OPL3 instead of General MIDI.

[Orchid87]

Have you tried playing the DOS version of Doom with the set dmxoption=-opl3 option? This improves the music when using FM Synthesis as it makes use of OPL3's extra channels and stereo panning. The only thing I don't get is why the Stereo is backwards when using OPL3 instead of General MIDI.

The problem is that Doom music wasn't composed with OPL in mind and it sounds just too weak in this mode. I like the FM synth when it is in the hands of japanese composers/programmers (the japanese retro computers music scene is amazing) but Bobby Prince is obviously not that good with Yamaha chips. Doom music is awesome in Sound Canvas and IMO should be this way. Heck even Wolfy sounds better in OPL mode than Doom.

[kool kitty89]

The problem is that Doom music wasn't composed with OPL in mind and it sounds just too weak in this mode. I like the FM synth when it is in the hands of japanese composers/programmers (the japanese retro computers music scene is amazing) but Bobby Prince is obviously not that good with Yamaha chips. Doom music is awesome in Sound Canvas and IMO should be this way. Heck even Wolfy sounds better in OPL mode than Doom.

I wouldn't say it wasn't composed with FM in mind . . . at least any more than the vast majority of other PC games were. Very few had particularly good use of FM, and that may have been due to the lack of experience of composers/programmers with managing really effective FM synth effects found commonly in Japan and Europe (that and many composers probably didn't even know how to program their own FM synth instruments, let alone handle such effects, so they were at the mercy of the MIDI or tracker software available to them -custom or otherwise-). This came up in the PC sound/music thread I started a while back. (there's also the separate odd issue of not using PCM samples in music along with FM)

Wacky Wheels is among the very few really good examples of FM synth on commercial PC games (ie not hobbyist chiptunes), using a nice selection of FM instruments and effects like echo/reverb. (some of the best FM drums I've heard in a DOS game, if not the best . . . among the best of any OPL2/OPL3 music for that matter -Madbrain's are obviously better though -albeit he definitely uses OPL3 specific patches)

http://www.youtube.com/watch?v=tfzg2vuqia0


http://www.youtube.com/watch?v=Vdg28fnGPAk


http://www.youtube.com/watch?v=ibrAagaj_Dw



Doom's music definitely could have been remixed/remastered to cater better to the capabilities of the OPL2 and OPL3 . . . albeit a capable sound driver and composer/programmer capable of using said driver would be needed. (more programming skill needed for a low-level driver, of course -a feature-rich, well-programmed tracker could be handled well by a composer without that though)

The GUS rendition could obviously be better too, though that really just needed different instrument samples (or different instruments chosen in general in some cases), though some remixing/tweaking to the tracks wouldn't hurt either. (especially to cater to the added flexibility of custom samples)