Cloudschatze wrote:
Lack of documentation/support was likely less of a contributing factor in poor-quality FM playback than was the choice to simply (and this is my opinion) follow Sierra's lead and compose specifically with/for the MT-32. In contrast, those developers that instead focused on the Ad Lib, for whatever reason and duration, managed to produce decent enough work. Here's one of the earliest such pieces, from 1988:
http://www.youtube.com/watch?v=GTV3kTo-1E8
That's perhaps not the best example to give since Hubbard was among the few stand-out computer game music composers of the time, among a few other (particularly European) composers/sound programmers. (off the top of my head, Tim Follin is one of the most obvious, as is Chris Hulsbeck, Matt Furniss also comes to mind)
It's my understanding that one of the major reasons European and Japanese FM computer/game music (be it PC, Arcade, or console) was often better than North American stuff was the development/spread of more advanced techniques specific to computer controlled FM synth. (on top of raw use of the synth chips themselves -ie various FM patches)
Among those are many examples of combining channels/voices for additional effects/sounds not possible by using plain 2 or 4-op channels, from simple use of additive synth/harmonization to reverb/echo. Some other techniques were outgrowths of those developed for simpler PGS-type sound chips (like the AY8910, SN76489, POKEY, SID, or the NES's Ricoh embedded sound), like rapid arpeggios simulating chords, software generated envelopes, vibrato, modulation effects, etc. (not to mention chip-specific exploits) For that matter, a lot of Amiga music uses those sorts of techniques too. (especially the simpler chip-synth stuff using simple waveforms)
And for that sort of stuff, you need good documentation with experienced/knowledgeable programmers and composers on top of that. (or very comprehensive software with built-in high-level support for many of those techniques/tricks)
Programmers, composers, and/or music software the treats the OPL simply as a 9-voice synthesizer would hardly be pushing its true potential. Real, rich and full arrangements would often only be possible when setting up an arrangement for fewer simultaneous voices than that to allow more complex sounds (via additive synth) and/or effects (like reverb/echo) as well as re-loading/changing instruments on the fly. (both in terms of the raw FM patches and in terms of channel pairing, since in this case a single "instrument" wouldn't necessarily use a single 2-op voice)
Wacky Wheels is most definitely not using simple 2-op voices for most of its instruments.
On a more general note though, Lucas Arts seemed to have relatively decent Adlib/SB support on top of MT-32 support (I'd even go so far to say that some cases were superior in OPL2 or OPL3 than MT-32 -I personally prefer X-Wing CD's and Tie Fighter's 4-op FM to the MT-32 renditions). OTOH, some developers who had little to no MT-32 support still only managed average sounding OPL stuff. (as with many id and Apogee games)
And in many cases where developers were apparently composing MT-32 tracks and directly translating (not re-aranging or remixing) to OPL midi, there's tons of examples of FM instruments sounding nowhere near as close to MT-32 counterparts as they could have (totally different instruments in some cases -not totally unlike MT-32 "emulation" support via AWE32 and such).
Composing tracks that don't cater well to FM in general is one thing, but simply remapping instruments poorly is another entirely. Sure, MT-32 music often wasn't ideally suited to the OPL2 (or OPL3) capabilities, but many cases could have been translated much more effectively, at least by using some custom patches/instruments to better correspond to MT-32 counterparts, if not more so. (reverb simulation, use of PCM channels -at least once SB support became common, etc)
And another note on the documentation issue: aside from normal documentation and tools released (well translated or not), there's the issue of bugs/quirks of chips that may not be addressed in standard documentation at all, but discovered by programmers and noted accordingly (worked around or exploited). It's certainly possible that Japanese developers had better and/or earlier access to this information (by experience or sharing/trading/collaborating). And it's also certainly likely that programmers (anywhere) working harder to understand any such quirks (in addition to new/different techniques in general) would be able to better utilize the hardware in general (and potentially write similarly better software).
These practices (in addition to synth techniques or "tricks" in general) seem to have been far more pervasive in Japan and Europe than North America.
The US-centric nature of DOS PC games of the time, as well as Japanese-specific platforms and popular European platforms (ST and Amiga were far stronger than in the US, and C64 got much later software support), so those are not directly comparable in many cases. The likes of the NES and Megadrive/Genesis are much more comparable though, with fairly broad software support from all 3 regions. (and in both cases, there's a significantly higher number of impressive compositions/arrangements from Europe and Japan than the US -albeit the NES is a less even example due to the huge percentage of Japanese developed games)
