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.
This is currently only used for Macintosh games, but I kept the name of
the setting anonymous in case we ever need gamma correction for
something else.
The only thing that remains in MacGuiImpl is the simplest form of
save/load disabling. Neither Loom nor Last Crusade use that, as they
have additional conditions imposed on them.
There is no need to disable menu items that are meant to stay disabled
more than once. This also adds disabling of some Maniac Mansion-specific
stuff.
Maniac Mansion seems to be running fairly well (user friendlyness issues
aside), though we need to figure out how to suppress the Mac GUI while
the game is paused. I also had it hang on me once on quit. No idea why.
There is currently no user friendly way to do this. You have to unpack
the Maniac Mansion files (since the game is not detected from the "Day
of the Tentacle Data" file), and then you have to put a copy of the Day
of the Tentacle Mac executable where ScummVM can find it (e.g. in the
same directory) because that's where the menus and dialogs are.
Known issues:
"About" shows the credits screen for Day of the Tentacle,
but the original behavior isn't much better: It just shows a black
screen.
The "Sound" menu should be disabled. There are some things I would like
to rearrange before looking into that, though.
This simplifies support for translated versions of v6-7 games where
apparently they sometimes kept the English texts and just added another
text on top of it.
I just added a step that is present in the second resource processing
loop of MacGuiImpl::createDialog(), but not in the first one.
(fixes at least SAM German, but possibly other things, too)
I mean, the color quantization is so broken it's not even funny, but it
is updating the thumbnail when the selection changes, and that's a
direct result of yesterday's dialog event loop restructuring. So I count
this as a win. Let's commit it before I break anything even worse.
Each dialog now has an event queue. The runDialog() method consumes all
ScummVM events and transforms them into dialog events. This should make
it easier to have widgets depend on each other, e.g. I want the v6-7
Open dialog to update the thumbnail picture.
This may have caused regressions, but initial tests seemed promising.
We know type 7 are controls, we just don't know (yet) what to do with
them. At the very least, we may be able to extract some texts from the
corresponding CNTL resource.
I had forgotten to skip the data for the user item when parsing the DITL
resource. For most games this made no difference because the size was 0.
But for Day of the Tentacle, that was not the case. It turns out that a
lot of stuff that I was drawing manually was there all along!
This one uses a regular dialog for About. Unfortunately, our Sam & Max
and Full Throttle Mac demos don't have any resource fork, and our Fate
of Atlantis Mac demo has an unrecognized string table.
This fixes transparency for the slider widget handles in v6-7 games.
Someone may want to adjust the image decoder later, but it will do for
now. Not all icons have useful masks, but some do.
When a dialog window is created now, all palettes from the individual
widgets (icons and pictures) are collected and combined into a single
palette. The widget palettes are remapped to this. The icon decoder is
now a proper image decoder, which makes icons and pictures very similar
to handle.
Apparently we need to figure out the appropriate size from the DITL
resource, which doesn't contain that information yet ResEdit somehow
remembers it? Hmm...
Previously, every palette change in a game get passed on to the Mac
Window Manager, which would then have to look up new colors for drawing
Mac GUI stuff. This was fine for some games, but later ones do a lot of
palette animations, which could slow things down.
Now the Mac Window Manager gets the new palette only when it's about to
draw the Mac menu, or when it's about to draw a dialog (since those can
be triggered outside of the menu).
Additionally, the Mac Window Manager now triggers the auto-opening of
the menu in the event handler, not in the drawing code. Otherwise the
menu would be drawn once before the SCUMM Mac GUI could notice that the
menu was visible, causing an ugly color glitch.
These games need the Mac GUI for more than just the menus and dialogs,
so for now if the initialization fails (i.e. the STRS resource was not
recognized, and could not be loaded) just disable the original GUI and
keep going.
Rather than crashing, allow the user to continue playing the
unrecognized Mac version, albeit without the Mac GUI. Certain other Mac
aspects may still survive.
Matthew Jimenez
Scott Percival
Torbjörn Andersson
athrxx
Cameron Cawley