earlier experimental version) after discussing it with LordHoto. This works
around a bug in the "Pool of Sorrow" Adlib data which caused the channels to
drift more and more out of sync for each time the music looped. The patch
forces the channels involved to jump in sync. As with all such workarounds, it
may cause regressions. But it shouldn't.
svn-id: r23659
- introduces Screen::getCPagePtr and Screen::getPageRect (which should ease the introduction of dirty rect handling)
- moves KyraEngine::loadBitmap to Screen
svn-id: r22716
Fix a lot of debug/error statements that were using %d/%x
for the result of pointer arithmetic.
As C++ apparently has no format string for ptrdiff_t use
%lu/%lx as appropriate.
svn-id: r21824
it's intended to do now.
Renamed _unkOutputByte2 to _vibratoAndAMDepthBits. It's a pretty terrible name,
but that's what it is: the two most significant bits of the Adlib BD register.
Renamed _rhythmSection to _rhythmSectionBits for consistency: It's the five
least significant bits of the Adlib BD register.
(The remaining bit is the rhythm on/off bit. I don't think we store that one in
any variable.)
svn-id: r21463
entering the castle. I hope this is a fair approximation of how the original
worked. Of course, this led to a couple of more renamings:
_unk5 -> _soundTrigger
updateCallback54() -> update_setSoundTrigger()
snd_setUnk5() -> snd_getSoundTrigger() (yes, "get")
At the moment, the only known sound triggers are the ones in the castle. If an
unknown trigger is set, the debugging messages will be really, really noisy. I
don't know if I should consider this a bug or an extremely annoying feature.
svn-id: r21396
directly. If they want a new data pointer, they have to use the dataptr
parameter. This fixes a subtle bug that would cause the wrong music to play
when getting the quill in Kyra 1.
svn-id: r21344
disassembly. I think they're correct now, and a bit easier to read. My old
comments were wrong, too.
I think they are for manipulating the Adlib rhythm section volumes. I'm not
sure the Kyra music ever uses the Adlib rhythm section.
svn-id: r21339
instrument. These are found using the lookup tables in _soundData on offsets 0
and 500 respectively. Added helper functions for that, which makes the code a
lot tidier. Particularly in update_setupRhythmSection(), where it's now much
clearer where it's getting all those "unk" values from.
Use the checkValue() function (which limits the "total level" to its valid
range) for the calculateOpLevel1() and 2() functions as well.
Renamed updateCallback16() to update_waitForEndOfProgram().
svn-id: r21337
updateCallback3() would call unkOutput2(9) in at least one case. This is
obviously wrong because it a) reads outside _regOffsets[], and b) writes to
invalid Adlib registers.
Now unkOutput2() has the same safeguards as noteOff() already had, making
callbackOutput() and updateCallback3() even more similar.
svn-id: r21335
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
bug is a bug in our fmopl.cpp. Ken Silverman's Adlib emulator doesn't seem to
exhibit the bug either. (But is apparently less feature complete than MAME's.)
svn-id: r21275
beginning of music" bugs. As an experiment, I tried hooking up ScummVM with the
most recent version of the FMOPL code, and the bug went away.
Unfortunately, I believe we are stuck with the ancient version for license (and
performance?) reasons.
svn-id: r21267
