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.
Torbjörn Andersson
AndywinXp