It will still trigger warnings about using a deprecated method, but now
it's clearly documented that this should be replaced with something that
matches QuickDraw's rounded rects.
Not that this is going to make any difference in performance, I think,
but it's a good way to test that the cicn loader is doing the right
thing when constructing that mask.
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.
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.
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.
Instead of referring to widgets by their ID (really just an index into
an array), now we ask the dialog for the Nth instance of a widget of a
particular type. So we still need to know in which order buttons and
such are defined, but it should still be a lot easier to read and a lot
less prone to error.
On a real Mac, the menu bar remains interactive while dialogs are shown.
This is only useful for the Edit menu during the Save dialog, and we
don't implement the Edit menu anyway. Ours is just decorative, but now
it looks a bit more like the original: Menus are grayed out or, for
About dialogs, the Apple menu is still highlighted.
Plus some other minor cleanups. As far as I can tell, Last Crusade is
the only one of the games that doesn't use the system save/load dialogs,
so it makes sense to me to let the base GUI implement it.
I think this is the correct rendering: Italics + Bold + Outline drawn
twice, once pixel apart. But ScummVM spaces the letters too closely
together. It could perhaps be fixed by adding Extended, but when I
mocked it up in a Mac emulator I didn't have to use that.
There is nothing "extra" about it. It's just a bold version of a font
that looks bold to begin with. I probably experimented with Geneva bold
before arriving at this, but now the special drawing for it is no longer
needed.
This is incomplete, but there are font rendering issues that others are
going to have to help me with, and this provides a test case. "Monkey
Island 2" is close enough that I may be able to figure it out soon, but
for "LeChuck's Revenge" the font manager picks a different font than the
one I asked for. (TTF instead of a bitmap font, I believe?)
We used to be able to use an unused area of the palette for the PICT
image's own palette. That will of course be quite impossible when
supporting 256 color games, so map the colors to the closest available
ones instead. That seems to be what the original interpreter did anyway.
Only 16 color games will be allowed to refer to the hard-coded colors.
This is a first step towards eliminating them from the code that's also
used by 256 color games.
This is to allow the "beam" cursor to be correctly drawn if it ever
moves that far up. There is no reason for it to, but it can happen if
you drag it outside the dialog window while selecting text.
This would happen if, while selecting text in an editable text widget,
you dragged the cursor too far down and outside of the dialog box. There
is no sensible reason to do this, but I was trying to mimic the original
behavior.
This was a regression from when the Mac screen height was increased from
400 to 480 pixels. The beam cursor is drawn manually, rather than by the
backend, because it's supposed to invert the background it's drawn over.
I did notice another regression, albeit a minor one: If you drag the
beam cursor to the top of the screen, it will corrupt the menu bar. I
think this is because the menu bar isn't drawn on the Mac screen. To
fix, we would have to copy the actual screen buffer instead, but I think
the only way of doing this is using lockScreen() and that's inefficient.
At least it shouldn't crash any more.
The idea here is to expose a much smaller part of the MacGui headers to
the SCUMM engine, but introducing a new class that simply relays calls
to the actual Mac GUI. I hope this will allow me to further untangle
things.
Le Philousophe
Torbjörn Andersson
Filippos Karapetis
AndywinXp