SCUMM: Remaining Mac GUI issues for Indy3 and Loom

[eriktorbjorn]

This bug collects known remaining issues with the Macintosh GUI for Indiana Jones and the Last Crusade, and Loom. Most of them too small to warrant their own bug report.

• We do not support the low-resolution mode used on 9" Mac screens. It's not something I have any personal interest in, but maybe there is someone out there who's nostalgic for it?

• In the original, the menu bar is activated by pressing the Command button. On PC style keyboards, this would probably be the Alt key, since that's how both Basilisk II and Mini vMac works. ScummVM instead uses the built-in feature to activate the menu when the mouse is moved to the top of the screen. This seems friendlier to touch devices, but it would be nice if we could support both. (Note that Alt-clicking is used by at least some window managers to drag windows, i.e. the click is not passed to the application.)

• The menu-auto-appears even when the mouse is hidden. (Though this may be necessary, because the mouse is hidden on the game over screens, and we do want to access the menus there.)

• The Edit menu isn't implemented at all. (Note that if we do implement clipboard handling, we have to make sure pasting text into an editable text widget does not exceed its maximum length.) I believe the original only uses the Edit menu for the Save dialog:

• As the Save dialog screenshot shows, the menus that aren't used for the dialog should be disabled. Except for the Apple menu, where the menus are still enabled and the Apple menu itself is highlighted:

• When loading images, ScummVM is not restricted to the 16 colors of the game palette, so it uses the ones from the image itself. This is probably technically an enhancement, but perhaps not something we need to fix or even flag as such?

• The "About" dialogs are recreated based on observed behavior, but I've taken some liberties. The animations in the Loom one are probably the most obvious difference. I think they maintain the spirit of the originals, but if anyone wants to go the extra mile to make them exact... Rounded corners are also drawn a bit differently.

• There is no "blinking" animation when selecting a menu item. Though on further investigation, it appears that this was always (?) configurable in MacOS. So not blinking isn't actually wrong... This is what I believe to be one of the earliest incarnations of the Macintosh control panel. Note the menu blink setting in the upper right corner.

• The Macintosh color palette is currently hard-coded. The games have a "clut" resource, but using that looks wrong so there must be something else involved?

• There are a lot of hard-coded texts that we should be able to read from the STRS resource. I wasn't sure how to do that correctly, though.

• Our save/load dialogs are a bit inconsistent. The Loom one is ours, built from scratch, where I added a "Delete" button that's not implemented. The Last Crusade one is built from the DITL resource, and doesn't have a "Delete" button. We should make up our minds about that.

• https://bugs.scummvm.org/ticket/12984 - Text centering in Loom is a bit off.

• The note names on the Loom distaff are not pixel perfect. Probably not even color perfect. The way I remember it, the original couldn't seem to make up its mind on whether they should be drawn with or without shadow and I couldn't find any pattern to follow. I don't know.

[angstsmurf]

I was a bit confused by this bit: "In the original, the menu bar is activated by pressing the Command (Alt) button."

As far as I can tell, the menu is activated by the Command (⌘) key, which is different from the Alt (a.k.a. Option (⌥)) key. The Alt key has no effect on the menu in these games.

[eriktorbjorn]

As far as I can tell, the menu is activated by the Command (⌘) key, which is different from the Alt (a.k.a. Option (⌥)) key. The Alt key has no effect on the menu in these games.

In the emulators I've tried, the Alt key is used as the Macintosh Command key. But I don't know if that's always true.

[angstsmurf]

In the emulators I've tried, the Alt key is used as the Macintosh Command key.

Doesn't seem to be the case in Mini vMac or SheepShaver, at least not on macOS, where they use the actual Command key. MAME seems to use left Control key as Command by default.

EDIT: Basilisk II also seems to use the actual Command key on a Mac keyboard by default.

EDIT 2: It also seems like a weird choice of key. If you use the Alt key to emulate the Command key, which key do you use to emulate the Alt key?

[eriktorbjorn]

EDIT: Basilisk II also seems to use the actual Command key on a Mac keyboard by default.

I haven't used a Mac keyboard since I retired my Mac Plus (which started out as a Mac 512K), so I wouldn't know. I had to look it up to even see that modern Macs still have the Command key. :-)

I just checked the documentation, though. Basilisk II:

On PC-style keyboards, "Alt" is the Mac "Command" key, while the "Windows" key is the Mac "Options" key.

Mini vMac:

In the Windows or X versions, the 'alt' key is used for the emulated command key, and the 'windows' key (or the 'application' key) is used for the emulated option key.

[angstsmurf]

Yeah, it kind of makes sense that they want the emulated keys to be in the same order as the keys on a Mac keyboard. Still a little confusing. If you plug a Windows keyboard into a real Mac, the Windows key will function as the Command key and the Alt key as Option. But this is getting off-topic.

[AndywinXp]

Thanks for the report! A few thoughts:

In the original, the menu bar is activated by pressing the Command button. On PC style keyboards, this would probably be the Alt key, since that's how both Basilisk II and Mini vMac works. ScummVM instead uses the built-in feature to activate the menu when the mouse is moved to the top of the screen. This seems friendlier to touch devices, but it would be nice if we could support both.

This seems unfeasible as it is... We have lots of combinations which use either ALT, SHIFT or CTRL both on the games and on the backend. There is literally no way that we can try to press one of those combinations and have the Mac menu bar open up instead.

The Edit menu isn't implemented at all. (Note that if we do implement clipboard handling, we have to make sure pasting text into an editable text widget does not exceed its maximum length.) I believe the original only uses the Edit menu for the Save dialog:

Yeeeaaah... I would just drop it entirely. Let's just have the edit menu with disabled submenus. 🙂 The Mac menu bar is part of an operating system and therefore it offers features which would have been supported by an operating system (i.e. a clipboard). We simply are not an operating system, so we kind of have to draw a line where to end implementing stuff we possibly don't need, and I think this is the line 😂 Let's just have it with all the submenus always disabled so it looks right and we don't have to implement things which are greatly out of scope.

Our save/load dialogs are a bit inconsistent. The Loom one is ours, built from scratch, where I added a "Delete" button that's not implemented. The Last Crusade one is built from the DITL resource, and doesn't have a "Delete" button. We should make up our minds about that.

IMHO it's not a bad thing to have them as they are: there are no DITL resources for Loom so emulating what we are emulating looks great for me. Maybe let's just disable those buttons which will never have proper usage for us, and that'll be okay.

Great work documenting all of these things!

[eriktorbjorn]

IMHO it's not a bad thing to have them as they are: there are no DITL resources for Loom so emulating what we are emulating looks great for me. Maybe let's just disable those buttons which will never have proper usage for us, and that'll be okay.

I was thinking mostly of the "Delete" button. That was something I added to my mockup, partly because the ScummVM save/load dialogs have one (at least in list mode), and partly because the dialog was looking so empty without one. And as long as it's not possible to save over an existing savegame, deleting could be quite useful.

If we plan on implementing save game deletion, it would be nice if both Last Crusade and Loom had it. If we don't, then it serves no purpose in the Loom dialog and should probably be removed from it. (Though it was a useful test case to see if opening a dialog from within a dialog worked.)

[angstsmurf]

This seems unfeasible as it is... We have lots of combinations which use either ALT, SHIFT or CTRL both on the games and on the backend. There is literally no way that we can try to press one of those combinations and have the Mac menu bar open up instead.

At least this one can be solved by using the actual Command/Windows key for this.

[AndywinXp]

Replying to angstsmurf:

This seems unfeasible as it is... We have lots of combinations which use either ALT, SHIFT or CTRL both on the games and on the backend. There is literally no way that we can try to press one of those combinations and have the Mac menu bar open up instead.

At least this one can be solved by using the actual Command/Windows key for this.

Being that those are system keys, I don't think they are ever being received by the ScummVM backend, so those would just be unusable as well

[angstsmurf]

Being that those are system keys, I don't think they are ever being received by the ScummVM backend, so those would just be unusable as well

I'm not familiar with the ScummVM code, and I realise that there are usability problems with capturing system keys. However, SDL will report the Command/Windows key as SDLK_LGUI (EDIT: returned as Common::KEYCODE_LSUPER by SdlEventSource::SDLToOSystemKeycode() in ScummVM), and the cross-platform Mac emulators discussed above use it to emulate the Mac Option key, so it is probably not too hard to implement if we wanted to. Not that I'm volunteering.

EDIT 2: I just tried adding some lines to the Scumm engine to print a console message every time the Command key is pressed (event.kbd.keycode == Common::KEYCODE_LSUPER), and it worked just fine.

[AndywinXp]

Sure, still I think that it's a less than ideal situation: I wouldn't want *any* program to override my system key behavior; what if I need to make the Windows menu show up for some reason and my mouse is already locked onto the ScummVM surface?

To have a simple but effective mouse-over behavior (like the one we have now) is much less disaster-prone IMO.