Some backends like GCW0 do no support graphics >320x240 due to
the hardware limitation (downscaling is possible but it will ruin
the pixel hunting which is often part of the gameplay).
Instead of manually updating the list of engines, we now introduce
a new dependency.
I marked all relevant engines, but some, like tinsel, require more
work with putting their relevant high-res games under USE_HIGHRES
define.
This fixes the delay outside the Frobozz Electric building.
In all other places, delay_render is called with a value
ranging from 1 to 10, so the 100 here looks to be a script
bug, and causes an unnecessary long pause in that scene.
Thus, we're capping the frame delay value to 10.
Fixes an edge case where the player goes to the dark room with the grue
without holding a torch, and then quickly runs away before the grue's
sound effect finishes. Many thanks to eriktorbjorn for the original
workaround
timedMessage() is always called from the scripting system. Which is updated before the rendering system.
Therefore, the message will already be rendered this frame, when the renderingManager->update() is called.
Before this change, text was drawn in black boxes in Zork Nemesis,
so while this does make it look better (and more like the original)
this may actually make the text slightly harder to read. The
original dialogs allowed only upper-case letters, but I think that
it's better to leave that to the player.
This is a bug in the original game script of the Zork Nemesis fist
puzzle, which we now patch so that the sound checks are correct for the
left fist animation
As suggested by Marisa-Chan. I had based my earlier implementation
on parseCritera(), and was unaware of this alternative. The good
thing is that the diff from the old code is now much smaller, which
should reduce the risk of regressions. (There is a lot I haven't
tested here...)
The volume can be either a constant or a state value. The latter is
used by ZGI to simulate a sound being heard at different distances,
e.g. the beehive in the Dungeon Master's hideout.
We have to update _curChunk when decoding audio, otherwise it will
decode the entire audio track on the first frame. For the ZGI intro
this would take 700-800 ms, and since the audio started playing
before the video it looked to me as if it had to play the first bit
faster to catch up.
Thanks to fuzzie for setting me on the right track with an off-hand
remark about the Zork AVI decoder (I was looking at the standard
AVI decoder), and for finding the cause a few seconds before I did.
