The whole restoreBlock() function looked strange. It said it took x, y,
w and h, but it seems pretty clear that what it expects is left, top,
right and bottom.
Except in one case, where the order of the parameters had been swapped.
The most visible result of all this was that The Feeble Files crashed
when you pressed the "Off" button in the Oracle interface.
I've changed the names of the parameters, and that one strange call, and
changed how the function calculates the dirty rect. Hopefully that
should be correct.
Just walking around the castle fixing bugs as I find them, e. g.:
- make decompression routine safer (this could write a couple of invalid byte in at least one case)
- also support compressed data header without actual data (required in the kitchen scene when killing the evil cook)
- fix some graphics/palette related glitches
- Add dual layer graphics display to display the Japanese characters in their proper (double) resolution on top of the graphics. The original actually uses text mode.
- Adapt mouse handling to dual layer code.
- For consistency I got rid of all direct calls to _system->lockScreen() and _system->unlockScreen(), even in the sub engines that aren't affected. I find it easier to debug and to maintain this way.
For each engine:
- Make a new folder detection
- Move detection-related files inside the folder
- Add a new module "enginename/detection"
- Add DETECT_OBJS here
- Adjust the normal engine module to remove detect_objs
- Adjust every file for the new changes.
Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
This attempts to restore the missing loyalty rating setting to the
4CD version of The Feeble Files. So far only for the English
version, since that's all I have, but it would not surprised me if
the other versions are similar.
This in fact slightly changes the priority order of added archives. Formerly,
all archives in SearchMan were preferred to the customly added ones in
ArchiveMan. All standard paths (i.e. path and extrapath) will be still be
searched before the custom ones (which are all priority 0 right now) but system
specific paths will be searched after (due to their priority being -1). Since
system specific paths shouldn't contain any game data files this should
hopefully be harmless.
This wasn't tested for games with CAB archives.
Now all of the Archive API is implemented to avoid possibly inconsistent
behavior when an ArchiveMan object is accessed via a class type higher in the
class hierachy.
Formerly the hasFile method was non-const, thus did not overwrite the virtual
hasFile method of SearchSet. Since all accesses to this function have been
done through a ArchiveMan typed variable, the missing overwrite should not
have caused any trouble.
It looks like this was forgotten in a6ec4f70da.
Playing with cabinet datafiles, this failed to find the "Charisma.smk"
file in the cabinets when in the Recreation (TV) room on Cygnus Alpha
and this caused an engine abort after the GUI dialog warning of the
"missing" video file. This was due to animation.cpp code using
Common::file::exists() instead of going via the ArchiveMan.
However,a hasFile() method implementation was also required to implement
fallback to decompressed (movie) files if the file requested is not in
the cabinet or the cabinet has been externally decompressed to files.
Thanks to fuzzie for the hasFile() patch.
Also, removed noisy warning which this correction triggers repeatedly in
installshield_cab.cpp hasFile(). This looks like leftover from
debugging, so not critical.
Now AgosEngine::_language is of type Common::Language instead of uint16. It is
currently only used with values of that enumeration, thus it should be safe to
use that type for it too.
The regression affected AGOS and maybe some others; specifically,
the real MidiDriver would have been deleted twice -- I previously
missed that the Engine instances takes care of freeing the real
MidiDriver, not the MidiPlayer wrapping it.
This commit should clarify the ownership of the real MidiDriver for
most pseudo MidiDrivers.
