Age | Commit message (Collapse) | Author |
|
Our warning() and error() functions always add an exclamation mark
to the end of the message anyway.
svn-id: r52791
|
|
svn-id: r50326
|
|
svn-id: r50324
|
|
using an assert.
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
|
|
svn-id: r47843
|
|
- Merge in some small OPL emulator changes from DOSBox's trunk
svn-id: r47546
|
|
/ company.
Check this for reference:
http://en.wikipedia.org/wiki/Ad_Lib,_Inc.
http://www.crossfire-designs.de/images/articles/soundcards/adlib.jpg (note the upper left of the card)
This commit does not touch "adlib" and "ADLIB" uses!
Also it does not update all the SCUMM detection entries, which still use "Adlib".
svn-id: r47279
|
|
selected OPL emulator does not support a mode asked for.
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
|
|
consistency
svn-id: r44634
|
|
svn-id: r40503
|
|
svn-id: r40502
|
|
svn-id: r40498
|
|
"opl_driver")
- Make MAME FM OPL the default emulator again
- Add GUI support for selecting the active OPL emulator
- Update themes
svn-id: r40496
|
|
- 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 some note that no one should use the legacy API for new code
svn-id: r40337
|
|
DISABLE_DOSBOX_OPL isn't defined.
svn-id: r40335
|
|
- 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
|
|
- Add new directory sound/softsynth/opl
- Move sound/fmopl to sound/softsynth/opl/mame
svn-id: r40333
|
|
svn-id: r38211
|
|
svn-id: r35214
|
|
svn-id: r35103
|
|
svn-id: r30968
|
|
Eliminate divisions, floating point, and mod operation from inner synth loop.
svn-id: r30896
|
|
svn-id: r29906
|
|
svn-id: r29741
|
|
been updated.
svn-id: r28966
|
|
svn-id: r28803
|
|
formerly knowns as Gaim) does; added new (incomplete) COPYRIGHT file; updated copyright dates in a few spots
svn-id: r27024
|
|
svn-id: r26395
|
|
svn-id: r24800
|
|
svn-id: r24257
|
|
svn-id: r24144
|
|
mistake, as DS port sets FMOPL quality in ds/arm9/source/osystem_ds.cpp
void OSystem_DS::initBackend().
svn-id: r24046
|
|
svn-id: r23621
|
|
svn-id: r23620
|
|
svn-id: r23619
|
|
versions are unaffected.
svn-id: r23552
|
|
svn-id: r23452
|
|
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
|
|
svn-id: r21055
|
|
svn-id: r20515
|
|
svn-id: r20314
|
|
svn-id: r20088
|
|
svn-id: r19735
|
|
svn-id: r19710
|
|
svn-id: r19142
|
|
svn-id: r19040
|
|
svn-id: r18756
|
|
svn-id: r18604
|