We do this by setting the _messageBannerActive flag. It's not really a
banner, I guess, but close enough. Also simplified the check a bit. Back
when it was just Loom and Indy 3, we checked if their custom banner
window had been created. But the message banner flag actually covers
that as well.
The userWriteLabelRoutine() seems to be used by several, but far from
all, of the SCUMM games when using the original GUI. Disable the
engine-default keymap while it's running, so that it won't clash with
text input.
This adds optional EPX scaling and 640x480 resolution for
LucasArts Macintosh games other than Indy3 and Loom.
This includes:
* Monkey Island 1
* Monkey Island 2
* Indy4
* Day of the Tentacle
* Sam&Max
* Full Throttle
* The Dig
In doing this, I reverted the ugly code which previously offset
the game screen 20 pixels below (to create an internal 320x240
buffer, instead of 320x200). Instead of just offsetting mouse
coordinates and the final screen texture, I used to offset the
in-engine graphics elements. Ew.
This ensures flawless savegame compatibility between old and
new, without touching anything.
...so users can't overwrite them.
This commit includes a small self-correction routine,
which moves all savegames down a slot, if the savestate
at slot 0 is non-empty and is not an autosave.
Now we instate a convention: on the original menus we
don't show the autosaves, ever. If an user wants to
use an autosave they will have to use the GMM.
Why? Because games with script based menus (v0-3, v8)
already exhibit this behavior, and I want consistency across
all SCUMM versions.
Naturally this commit excludes all HE games, since they
can't use anything other than the GMM, to save and load.
No more cases of SCUMM quit dialogs followed by frontend
quit dialogs, and no more cases of versions not having an
override quitting without confirmation (ignoring the frontend
setting).
Algorithm taken from SAMNMAX disassembly.
INDY4 and DOTT share another earlier algorithm, but I couldn't
understand the code enough to know if the resulting effect
is different or not.
This closes and fixes#11971:
"SCUMM: MANIAC/ZAK C64: GUI & dialog text are incorrectly
positioned on screen, and cursor is improperly layered"
The ticket also mentions improperly layered cursor:
"the pointer cursors pass *behind* the various character sprites
on screen", but there's really nothing we can do about it,
our cursor handling is way too different to function like the original
(and anyway, it looks like a severe C64 hardware limitation quirk...)
Poor Apple II version, it has been broken for at least a couple
of years :-)
All regressions were a byproduct of basically forgetting this
version existed when making changes which should have
(or should not have) targeted C64 games, which use the
same rendering routines and palettes as this one.
Fixes and closes#14765:
"SCUMM V0: MANIAC: APPLE II: Palette is incorrect."
Whenever _screenTop is non-zero the edges of GUI elements
will glitch during SMUSH movies. This happens on the originals
as well (the ending movies for DIG and COMI), but to a less extent.
("INDY3 (FMTowns): Map lines are drawn incorrectly, plus more
issues when leaving Germany")
The bug with the wrong colors is caused by the shadow palette, which
gets set with the colors for the modified country borders, but gets
reset immediately after drawing the background. So when the map
travel marker makes an area dirty, it would be restored with the wrong
color. Now, the original V3 FM-Towns interpreter can draw on layer 2
directly, without declaring anything dirty, effectively bypassing the
normal SCUMM drawing. This avoids any change to the background.
This happens for drawBox, but also when displaying or hiding the pause
banner.
In SCUMM5 drawBox works the way we had it implemented, drawing
on the text surface (MI1: also on the vs buffer) and then making that
rect dirty.
(INDY3 (FMTowns): Map lines are drawn incorrectly)
This fix addresses the part concerning the line width of the travel
marker. Turns out that SCUMM3 FM-Towns draws all boxes one
pixel wider and higher on virtual screens other than 1. This also
allows removal of a hack in ScummEngine_v5::o5_drawBox().
I also fixed the old style pause/restart banners, since they incorrectly
used drawBox() for line drawing (which would be glitchy with the now
verdrawing drawBox(). The positive outcome is that we no have original
looking FM-Towns banners (only in Japanese, though, since - unlike the
original - we don't run the English version in 640x480).
The changed method of drawing and removing the banner also fixes
the removal of the black country borders on the map. But it will still
be removed below the pause banner and in the spots where the travel
marker passes the border. So that has to be addressed separately.
I wired up almost every Indy3 option (except for audio, which
might need some special handling), and I implemented the
scrollable text list in the save menu.
We now quit without confirmation when the scripts tell the
interpreter to quit. Except in COMI main menu, when pressing
on the "Quit" option. In that case we must ALWAYS show the
confirmation dialog box.
The intent was to pass zero arguments using dummyArgs, but that would
have caused out of bounds reads because runScript expects an array of
size NUM_SCRIPT_LOCAL (25). Passing `args` worked because it was
already zeroed out, but runScript also accepts null for this purpose.
See: 19b45e2a50
This happens on screeens with an xstart offset (= a screen
that is wider than 320 pixels, after some scrolling) but only
when there is dialogue text on screen when pressing F5.
Can be tested right at the start on the bridge. Just right-
click the sign, then press F5...
This was caused by the fact that the pre and post save screen scripts
were not being called, and this messed up the cursor state with savegames
created as quicksaves.
Also, renamed the variables containing said scripts numbers, so that
they are a little bit more meaningful now.
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!
This only affects the original GUI mode, and leaves the other mode as it has always been; also,
the issue only appeared when the global configuration parameter "confirm_exit" was set to true.
Torbjörn Andersson
Cameron Cawley
AndywinXp
athrxx
sluicebox
Eugene Sandulenko