The new DBOPL emulator we are using should support multiple instances though. We *might*
consider allowing as many instances as the user wants. Of course since the original
games only had one OPL chip available, that should not be required. Also just in case
we might allow real hardware as playback device that would be out of the question again
too.
svn-id: r48183
We will now output a warning to the user in this case. That should be fine,
since SCI is the only engine so far, which uses Dual OPL2 emulation.
Albeit this is not supported by our MAME emulator the user will still get
sound output, since the SCI engine will do proper recovery and fallback
to single OPL2 emulation, which is supported by the MAME emulator.
In case a engine would require a specifc mode (like OPL3) and the
user selects MAME emulation, this might result in no sound output
(or a crash), in case the engine does not take any care of testing whether
the OPL creation succeeded. But luckily so far no engine does this,
so it should be fine to not worry about that for now.
svn-id: r46140
- Rename OPL_DOSBox to OPL, since it's inside a seperate namespace anyway
- Reanme MAME_OPL to OPL, since it's inside a seperate namespace anyway
svn-id: r40338
- Add new OPL emulator API (and legacy access API) in sound/fmopl.h
- Add DOSBox OPL emulator.
- Update MAME OPL emulator for the API changes.
svn-id: r40334
while still at the very beginning of the "attack" phase. This is the very
lowest point on the attack curve, yet it would continue from the beginning of
the release curve, i.e. its very highest point. This is what caused Kyra to
often play low-frequency notes at the very beginning of a new song. (That, and
a truly bizarre function for initialising the channels.)
The proper fix would be to locate the correct point on the release curve and
continue from there. For now, though, only handle the trivial case.
svn-id: r21302
(Unfortunately, this does not fix the Kyra bug I'm looking for.)
In the most extreme case:
* DR and RR will point to &DR_TABLE[60], and AR will point to &AR_TABLE[60]
* SLOT->KSR will be 0
* CH->kcode will be 15
In that case, it will attempt to access AR[15], RR[15] and DR[15], i.e.
AR_TABLE[75] and DR_TABLE[75]. So these arrays need to be 76 elements, not 75.
We used to initialise element 75, but this was changed to 74 to match the size
of the arrays. Buf if my reasoning is correct, it was the arrays that were too
small.
svn-id: r21301
Test built for Symbian and run on P910i without any major problems.
Test built for MSVC6. Changed parts seems to compile ok but there are some problems with MSVC6 and some of the targets which the EPOC build does n't support (KYRA,SAGA).
svn-id: r18430
