SCI: Add some comments a possible TODO regarding song looping
This commit is contained in:
parent
9999a0e210
commit
6fa668e32a
1 changed files with 16 additions and 1 deletions
|
@ -536,6 +536,11 @@ void MidiParser_SCI::parseNextEvent(EventInfo &info) {
|
|||
// Check if the hold ID marker is the same as the hold ID
|
||||
// marker set for that song by cmdSetSoundHold.
|
||||
// If it is, loop back, but don't stop notes when jumping.
|
||||
// We need to wait for the delta of the current event before
|
||||
// jumping, as in LSL6, this ends up jumping forward one tick
|
||||
// (the hold marker occurs at playtick 27, with loopTick
|
||||
// being 15 and the event itself having a tick of 13,
|
||||
// total = 28) - bug #3614566.
|
||||
if (info.basic.param2 == _pSnd->hold) {
|
||||
_jumpToHoldTick = true;
|
||||
}
|
||||
|
@ -640,7 +645,17 @@ void MidiParser_SCI::parseNextEvent(EventInfo &info) {
|
|||
// (e.g. song 110, during the intro). The original interpreter
|
||||
// treats this case as an infinite loop (bug #3311911).
|
||||
if (_pSnd->loop || _pSnd->hold > 0) {
|
||||
// We need to play it again...
|
||||
// TODO: this jump is also vulnerable to the same lockup as
|
||||
// the MIDI hold one above. However, we can't perform the
|
||||
// jump on the next tick like with the MIDI hold jump above,
|
||||
// as there aren't any subsequent MIDI events after this one.
|
||||
// This assert is here to detect cases where the song jumps
|
||||
// forward, like with the hold jump above (however, this
|
||||
// scenario sounds less likely to occur with this jump). Note
|
||||
// that we haven't yet found a scene where this jump might
|
||||
// lock up,
|
||||
assert(_loopTick + info.delta < _position._playTick);
|
||||
|
||||
uint32 extraDelta = info.delta;
|
||||
jumpToTick(_loopTick);
|
||||
_nextEvent.delta += extraDelta;
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue