This should provide more accurate and feature complete
sound than the existing player (which is still there, just
disabled). I haven't implemented a proper quality selection
method yet.
If we show the "Audio files compressed with ScummVM Tools were detected"
message, we are in the middle of initialization. If a user tries to
launch the GMM while the message is still on, it will lead to a crash.
The new Mac GUI doesn't change the savegame format, but it removes a
couple of verbs. It can read old savegames just fine, but new ones will
not be usable by older versions.
This is still just a mock-up, and a bad one at that. It will all be for
nought unless I can figure out how to wire up these buttons to the SCUMM
verbs.
E.g. when exiting the lost dialogue of Plato screen in INDY4,
sound would dip down for a fraction of second. This is a result
of a workaround of our own, which should be disabled during
heap/temporary saves handling.
The issue, although minor, was there because of a workaround
which is incompatible with what the original HE code is trying to
do at that point; removing that workaround for HE games fixes it.
This fixes an inaccuracy in situations where a talkie
continues after exiting from a temporary save state,
e.g. looking at the National Archeology journal in Indy4
and exiting the screen before speech is over.
This get rids of a whole class of sound glitches across the
engine, where temporary saves paused sound for a fraction
of second, resulting in a hiccup.
Examples: reading the dialogue of Plato in INDY4, looking
at the recipe book in COMI.
Concept suggested by eriktorbjorn, and proved by the fact
that disasms do not pause audio at when saving.
This is the same problem that has affected version 6 games and Mac Indy
3, so hopefully this fix is enough. I changed the _macScreen check to
check for platform, since that seemed more sensible to me. Some day, we
should probably get rid of the ability to play the Mac versions in low
resolution anyway.
zlib is used when available and falls back on gzio.
This allows performance improvements as our CRC32 and gzio
implementations are slower than base zlib.
As zlib is available when libpng is present, this is sensible to
benefit from it.
This commit properly takes care of #10854 and #1016;
the previous code was retrofitted from v5 and thus potentially
presented inaccuracies (e.g. room 1 in LOOM CD shouldn't
cycle colors).
A post-load fix was also necessary for older savegames,
otherwise color cycling would not occur at all until the room
was exited and then re-entered. Being that the cycling data
was being mangled by the previous implementation, there was
no choice but to introduce a new save version to detect this.
Cursor is handled differently in this Mac port, i.e. without
setting values in the _cursor object. The CursorManager
doesn't exactly like that, so in this commit I've provided a
post-load fix and a fix for the cursor initialization itself.
This fixes a crash when loading from the GMM save states which had
been created from the original menu. This also fixes the auto-close of the
menu when a game is loaded from the original menu.
I really have no idea why I wrote the code in such a way that
it attempted to load stuff that was never saved in the first place,
and I guess we'll never know. Findings by athrxx!
As much as this seems bad design, it's a real possibility in the original interpreters, furthermore
confirmed by the menu messages which are shown when the user tries to do that, so here we are...
This commit implements saving and loading in the same way the original interpreters
for MANIAC v0-1-2, ZAK v1-2-3, LOOM v3 and INDY v3 do. This makes it possible to
use the original save menus without glitches or crashes.
Saves done from GMM can also be loaded from the original menu.
This fixes an issue in which saving a game in a situation in which the camera
is frozen (i.e. having the inventory open) and then reloading it, doesn't keep the
camera state, leading to slight graphical glitches. The original interpreter saves this
parameter, so we better do that too.
The new GUI code has a variable of the exact same name in the base class scope. It does not cause issues for me, but I guess it would at least provoke a warning on some compiler. We really don't need to wait for that...
I also renamed the _savegameThumbnailPalette, just for consistency.
From now on we're reasoning in terms of text speed, just like the interpreter does,
which means: delay == 9 - speed.
This allows us to sync the internal GUI and the ScummVM GUI more easily, and
allows for a better correspondence to the original interpreters.
I used kISO8859_1 which works fine most of the
time, but it is still not correct. Now, we just call
getDialogCodePage(), so we get the code page
that matches the current game font...