(This is basically an unnecessary emulation of a hardware limitation. EOB II will try to load approximately 70 KByte of samples for the outro sequence, which would lead to some missing sounds with the 64 Kbyte limit).
These occurred while compiling in Raspberry Pi Raspbian latest and
appear to be due to char being interpreted as unsigned by default,
rather than signed in two data structures. Have replaced with explicit
types to avoid this issue.
This is a regression from 90b78c544657bf0fc41d6b86276a0873060345b5
This commit restores the previous behaviour and avoids a null
pointer dereference induced crash.
This fixes the root cause of bug Trac #10515.
The action which triggers the assertion is CheckUnderBedDB.
This changes ActionPlay::OnStart method to be similar to superclass
implementation with regard to _startFrame to avoid this.
However, the animation still glitches repeating several times, but this
is a script bug in the original and should be addressed in a workaround
in a future commit.
This should fix the main issue in Trac bug #10800.
This bug would occur when casting dispel magic while the weapon slots were temporarily disabled (from using a weapon etc.). This could lead to permanently disabled slots.
In all my attempts to get the audio and video to sync up in the
ZGI videos, there have always been 9-10 frames of video before the
audio even starts, even though the audio is timestamped to start
before. This attempts to fix that by prioritizing sending audio
packets to the decoder in a timely fashion.
I do not know if this is the correct way of doing this, and there
are still some things that need to be fixed. But pragmatically, it
does procude significantly better sync, so...
Sometimes (only at the very start of a movie?) there will be a
video packet that has a PTS but no frame to display. Save that PTS
and use it for the next frame. This doesn't actually improve
anything, as far as I can tell, but feels right.
This is another attempts at improving the audio/video sync in the
MPEG-PS decoder. Unfortunately, the audio probably also needs to
be synced to its pts timestamps...
From what I understand, this has something to do with the image
being either made up from two or three parts. When it's made from
three parts, the frame should be displayed for half again as long
as normal.
This makes the speed of the Zork: Grand Inquisitor video look
about right to me. It's still out of sync, but it doesn't seem to
get *more* out of sync as the video progresses.
This code comes from clone2727's now defunct (?) ac3 branch, with
some minor compile fixes. This represents the latest version of
the stalled AC-3 decoder work for Zork: Grand Inquisitor. Note,
however, that I have not yet asked for clone2727's permission to
use this. I'm just experimenting.
