Untangled the audio and video track from each other, and the parsing
of the stream from the decoding of its data. Also fixed a memory leak
as it turns out deleting a Surface doesn't free its data. You have to
call free() in it.
I have only checked the intro, not every cutscene, but that seems to
work fine at least.
As an alternative to using the Screen class's functions, we can let
the VQA decoder draw directly to the backend. This won't work if the
game uses "hi-res mode", but I don't think that's ever the case for
Malcolm's Revenge. I believe the KyraEngine_MR::playVQA() function
ensures that the screen is properly updated after the movie has
finished.
This almost limits the VQA rewrite to vqa.cpp and vqa.h. Whether it's
better this way than changing the Screen functions to take a 'pitch'
parameter...? I don't know. But it's an alternative.
Each engine now only has to provide a single configure.engine file
adding the engine into the configure script, which then produces the
required other files automatically.
This is the third and final commit enabling fully pluggable engines.
Now providing an engine folder contains a configure.engine, engine.mk
and engine-plugin.h file, it will be picked up automatically by the
configure script.
This is the second part of allowing engines to be added dynamically.
Each folder in engines/ which must contain a file named "engine.mk"
containing the make definitions for that engine.
This is the first part of allowing engines to be added dynamically.
They are placed into a folder in engines/ which must contain a file
named "configure.engine" to add the engine, which is pulled into the
top level configure script automatically.
Although I did not consult with disassembly, judging from the game
logic _unkEndSeqVar4 is used for switching certain Malcolm frames,
and it is apparent that this should happen only under condition,
not always.
This allows to keep the engines to specfiy the files for translation close to
the engine sources itself.
Thanks to criezy for his suggestion on this approach.
There are two ways that the music volume may be set:
The setSourceVolume() specifies the current music volume, as
ScummVM sees it. This is stored in _sources[].volume.
The MIDI data itself can trigger volume events. These are handled
by send(), which stores the volume - usually (always?) 100 - in
_sources[_curSource].controllers[]. The volume is then adjusted
by _sources[].volume.
When music is faded out, setSourceVolume() is called repeatedly
with progressively smaller values for the volume. What it should
do, then, is to make sure that the volume is set to what was
previously set to in send(), adjusted to the fading volume.
At least, that's how I understand it.
