ScummVM versus native interpreters

[Udvarnoky]

What with recent talk about CMI's music implementation being iffy in ScummVM, I thought it might be worth trying to compile some of the known behavioral differences in the SCUMM games when comparing the original executable (as run in an emulator like DOSBox or, for you nuts out there, an actual old IBM or Amiga) to ScummVM's interpretation.

I'm doing this mainly for my own benefit, as I get the impression certain folks are aware of more discrepancies than I am, but I'll kick things off with some that I know about:

- Most obviously, ScummVM does not reproduce the original UI for things like pause state, "Are you sure you want to quit?" and Save/Load menus. In several of the games, the save menus were pretty generic, but Maniac Mansion for example gave you a unique image (Syd running away from Green Tentacle in v1, Green Tentacle's band jamming out in v2), and Last Crusade had a graphic representation of your IQ score.
- In Maniac Mansion, saving was not allowed once you reached Dr. Fred's lab. Hitting F5 at that point brought up this text: "The Meteor has control of your computer and he won't let you save the game." Last Crusade similarly wouldn't let you save once you hit the Grail Temple, as an in-game sign warns. ScummVM lets you freely save your state in these final sequences.
- Starting I think with Hit the Road, the games shipped with custom launchers that ScummVM bypasses. Unlike the creepy teal/purple one for configuring sound on Fate of Atlantis and Day of the Tentacle, these GUIs were visually designed in the flavor of the game.
- Maniac Mansion NES is rather graphically glitchy, most noticeably when characters climb thin air instead of the stairs to the third floor landing. ScummVM also makes it so that the steel security door is always open as it is in the PC versions. That is done to bypass the copy protection - a "crack" which became part of the official executable when bundled with DOTT - but there was never copy protection in the NES version. The security door was simply unlocked.
- CMI's iMUSE isn't faithfully replicated in ScummVM. It appears that local hero AndywinXp corrected this within the last year. Note that folks who purchased CMI off of GOG/Steam will probably need to grab the latest dev build of ScummVM, as the version that comes bundled with the game almost surely predates the merge of this fix.

[s-island]

3 hours ago, Udvarnoky said:

- Starting I think with Hit the Road, the games shipped with custom launchers that ScummVM bypasses. Unlike the creepy teal/purple one for configuring sound on Fate of Atlantis and Day of the Tentacle, these GUIs were visually designed in the flavor of the game.

The launchers were a separate, convenient tool included with the CD versions of the games so that you could easily run the various rolling demos as well as the games. The fastest way was always to just run the game's EXE directly.

[Udvarnoky]

It also let you configure your sound boards! Which may have resulted in nothing more than appending an "s", an "a", or an "i" as an argument to the EXE, but consider the cultural losses of denying modern players this screen.

 

[s-island]

That's a separate program to the launcher. From Hit the Road and onwards, iMUSE had its own setup program that generates a config file the EXE reads by default instead of command line parameters.

[Elle]

1 hour ago, Udvarnoky said:

... consider the cultural losses of denying modern players this screen.

 

 

I know, right? This screen is beautiful.

[ATMcashpoint]

NB: I'm having trouble getting a password-recovery email for my usual account (the problem seems likely to be on my email server's end) so I'm using this backup I created when the forums first came back online and the recovery of ancient accounts had issues. - ATMachine

 

ScummVM used to have an Alt-F5 hotkey that would bring up the original Save/Load menu. This has stopped working in current builds (including one I just downloaded today). This means, for instance, that you can't see the "enable 3D acceleration" joke in the CMI menu. So in at least one case actual game content is being lost as a result.

 

ScummVM's implementation of Sierra SCI and AGI games has a check-box option in the launcher menu to enable the original Save/Load GUI. Even when Alt+F5 worked, ScummVM never had anything so intuitive or easy to use for SCUMM games - it was always relegated to an obscure keyboard command, which now doesn't even work. It's a clear example of the way SCUMM support has lagged behind games from Sierra etc. in the last few years. I'm glad to see other people besides me are taking an interest in this stuff.

[s-island]

The SCUMM GUI behaviour and look was hardcoded in the EXE itself for every game. It's not run by the scripts. They'd have to do the same in ScummVM for every game and I guess nobody on the team cared enough about that to continue supporting it.

[ATMcashpoint]

I mentioned it in a #monkey-meetings chat on Discord a couple months ago and was told by Sev that it was a bug and I should file a bug report. Which I duly did, only to have it closed a couple days later because it was a duplicate of a (still-open) bug ticket that was already a year old at that point.

[s-island]

ScummVM uses the wrong CGA palette for Loom and The Secret of Monkey Island. I haven't compared the older games.

The original interpreter uses the default high intensity cyan/magenta palette as can be seen this screenshot from DOSBox:

ScummVM uses the low intensity variant for some reason. It also uses RGB values for each colour that appear to be slightly off compared to the values I can find everywhere else. The CGA cards originally controlled their monitors using different voltage levels instead of digital values so it'll always be an approximation, but it's still a bit odd.

[Udvarnoky]

@ATMachineYeah the ScummVM project is...known for that.

 

I don't want to rag too much on ScummVM because Lord knows it's been a godsend for as long as it has existed. You can't beat it for convenience or for the ability to play various wacky versions of titles that you may find yourself for totally innocent reasons not happening to possess the executable (or maybe even the platform) for.

 

But I think the quiet disregard of the native interpreters over time poses an archival issue. I have mixed feelings because there was a time when I would have considered it a pipe dream to have all the LucasArts SCUMM games officially available again. And now, here we are: they're all easily obtainable from GOG and Steam...bundled with ScummVM.* Which I don't object to, as it's free and a great way to ensure every game "just works" out the box for roughly every end user imaginable. But because ScummVM functionally replaces those EXEs, it seems Lucasfilm saw no need to toss it in with the data files while they were at it. Luckily, Archive.org is surprisingly well stocked in this regard, but it's kind of sad that even with the games legally available, people are still left to turn to Warez sites if they want to pursue the option of running the games exactly as they did when they shipped. Or, worse, they have to put down the cheese popcorn in order to walk to their closet and disinter their old bit-rotting floppies.

 

*I believe the Steam versions of Indy3, Indy4, Full Throttle and The Dig may use the upgrades executables Aaron Giles made at LucasArts circa 2002, which is cool. Shame LEC didn't spend the extra five cents to do all the games...unless they did and just never cared enough to put them out.

[ATMcashpoint]

Not to mention that current daily builds of ScummVM on Windows default to an OpenGL rendering mode where you have no way whatsoever to simply take a 320x200 resolution game and upscale it to 2X, 3X, etc. with the window fitted to match. Instead it resizes the game screen by default into a very large and distorted resolution, around 1152x864. And the only way to resize the game window is through the extremely imprecise method of using Windows' resize function to make it into something vaguely near the resolution you want.

 

So you either get horrible pixel stretching, with stuff like the pixelated cursors no longer fitting 1:1 on the background art - along with very noticeable letterboxing/windowboxing if you try to resize it - or (if you use the "Center" option in the launcher graphics settings) a tiny 1x window swallowed up in a void of black.

 

 

 

Apparently the way to change this (as I just figured out after some frustrated tinkering) is to go into the launcher options and select "SDL Surface" as the render mode rather than OpenGL, which allows you to have game windows with pixel-perfect scaling. But the result is that the default presentation of LucasArts games in current ScummVM builds looks absolutely atrocious. I don't get at all why this is the default, and there isn't really any explanation in the launcher to help people find the better rendering options.

Edited August 14, 2021 by ATMcashpoint

[Elle]

This is crazy, I had no idea that support for official SCUMM games was lagging behind. These past few years I've mostly been using ScummVM for the other games it supports, and they all work amazingly well.

[s-island]

OpenGL has been the only way to get proper scaling of the non-square pixels in 320x200 games at 1600x1200 because it's the only renderer where aspect ratio correction and scaling is done in the same pass. Does that work with SDL Surface? The problem is that ScummVM does not let you set the resolution directly. Instead you're forced to use their odd collection of scalers or resize the window manually and hope it ends up at 1600x1200.

[Elle]

It's been a while since I've last played a legacy SCUMM game in ScummVM (what with the recent onslaught of remasters and such), but isn't there an option called Force aspect ratio correction or something like that? I seem to recall using that.

[s-island]

Force aspect ratio correction will stretch 320x200 games to 320x240 so you get the right aspect ratio, but since 240 isn't divisible by 200 you end up with some of the original pixels being twice the height of the others. It looks a bit uneven. The pixels of 320x200 games were 1.2 times as tall as wide, or 1.2:1. They weren't square. Ideally, these games should be run at 1600x1200. 1600 / 320 = 5 and 1200 / 200 = 6 so each original pixel would be scaled up to be 5 pixels wide and 6 pixels tall. Since 6 / 5 = 1.2, they would then keep their original shape.

 

In ScummVM, OpenGL can do this because it performs aspect ratio correction and rescaling in one pass. The problem is that the GUI doesn't allow you to specify a resolution directly. You have to resize the window manually and hope it hits on the right resolution.

 

DOSBox lets you set the resolution directly in its config file.

[Elle]

Holy snugglecakes! You've just made me realize how utterly oblivious I am to the technical rendering of pixel art. Thanks for the explanation, though!

[s-island]

Hahah, yeah, things can get a bit crazy when you try to run those old games that were made for CRT monitors on modern displays. Since CRTs don't have fixed pixels, they could be any rectangular shape so there's always some compromise when trying to display them on LCD monitors.

[Jake]

It’s bizarre that scummvm doesn’t have a -w -h launch option, even if they don’t want to make a UI for it. 

[Udvarnoky]

I've been re-downloading my LEC purchases from GOG, and I noticed some of the games have the native interpeter stuffed into a directory called "other". So that's pretty cool, even though it appears to be an inconsistent inclusion.

 

Another wrinkle is that some of the earlier Steam releases of the LEC SCUMM catalog (the two Indy games and The Dig) came with the Windows-friendly executables that Aaron Giles made for LucasArts in the 2002ish area. Allegedly he actually updated all the SCUMM games this way, but only Hit the Road and Full Throttle surfaced at the time (as part of a UK compilation box, I believe), then those few others quietly appeared on Steam years later. The majority never saw the light of day, and at some point it seems Lucasfilm just found it easier to bundle ScummVM for all subsequent digital releases. (GOG may also use ScummVM instead of the Giles executable for the aforementioned Steam titles, though that needs fact-checking.)

 

Cataloging exactly what data files and launchers come bundled with the GOG/Steam releases seems like a worthy mission for someone unburdened by my laziness.

[ThunderPeel2001]

On 8/13/2021 at 2:23 PM, Udvarnoky said:

- Last Crusade similarly wouldn't let you save once you hit the Grail Temple, as an in-game sign warns. ScummVM lets you freely save your state in these final sequences.

 

I opened a bug for this months ago: https://bugs.scummvm.org/ticket/11948 I hope one day someone fixes it.

 

ScummVM is heavily reliant on volunteers, obviously. What they've managed to do is really quite a miracle. Especially with games like Blade Runner where they've added lost scenes and puzzles, etc. But yeah, when you're a die-hard like us, it can be frustrating that things aren't pixel perfect -- even though they have a continuous stream of pull requests, there's endless work to be done! (I have daydreams of finally committing time to the project, becoming an amazing coder, and fixing all the niggling issues that bother me.)

 

I managed to persuade one amazing person to fix the clocktower bug in the CD-ROM version of SOMI. Turns out the CD-ROM version of the game has a ton of weird bugs in it, as if a developer tried to bug fix it by reading the code. That particular one has bugged me for decades. The dev fixed a few more things like this, too: 

 

https://github.com/scummvm/scummvm/pull/3239

https://github.com/scummvm/scummvm/pull/3252

https://github.com/scummvm/scummvm/pull/3253

https://github.com/scummvm/scummvm/pull/3211

 

They're a damn hero, I tell ya!

Edited September 3, 2021 by ThunderPeel2001

[Jake]

27 minutes ago, ThunderPeel2001 said:

 

I managed to persuade one amazing person to fix the clocktower bug in the CD-ROM version of SOMI. Turns out the CD-ROM version of the game has a ton of weird bugs in it, as if a developer tried to bug fix it by reading the code. That particular one has bugged me for decades. The dev fixed a few more things like this, too: 

Are these being fixed in a way that you can disable the "fixes" with a flag or something? It seems strange that ScummVM is now fixing bugs (without any understanding of why they're fixed) in a way that doesnt let you experience the original version without resorting to DOSBox. I mean, you're probably right that they are bugs, but without knowing for SURE, it seems bold to straight up alter historic game content when its run through ScummVM. Why is it ScummVM's job to fix these, especially in a way that is opaque to end users?

 

I realize that I've been working on remasters of Sam & Max games that change a TON of content, so I understand the line can be blurred, but in the case of Sam & Max we made them explicitly new releases, and leave the originals untouched.

[ThunderPeel2001]

Hmm. These are straight up bugs once you look at the code and see what's going on. It's just like when they re-enabled the blocked dialogue tree in Grim Fandango. I think worrying about bugs being fixed is taking preservation to another level ("I want to play the version where I can't ask Domino about his plan!"). You always have DosBOX for the die-die-die-hards who want to see the original versions. I'm glad ScummVM is merging these fixes myself.

[Jake]

If the confidence level is really high that they're bugs that's more okay, but it still weirds me out a little bit.

[Thrik]

Yeah it’s an interesting one.

 

The archivist in me thinks that fixed versions of games should be versions of games, and not a pseudo version that sort of arises from the emulator/tool massaging the implementation.

 

For example there are numerous editions of Monkey Island 1 & 2 that were released for various platforms with many small variations. Should the tool be smushing those variations into one definitive version, or letting the differences stand — like a missing prop description, or minor dialogue fixes?

 

If so, then what about bugs? Different versions of classic games have different bugs because of how patches didn’t exist back then. Should the tool also smush those fixes together?

 

I think for casual players or those seeking the ‘best’ experience then it does make sense to do the above. However, few casual players are going to be using ancient versions of games and trying to run them on modern systems — they’ll just pick up the Special Editions.

 

It’s going to be enthusiasts playing these old versions, for whom I feel the tool’s primary job is to preserve the original game exactly as it was, and if there is any ‘fixing’ that is done very transparently in a toggleable way. Otherwise, what if you do want to play SOMI with its bugs intact — whether it be for the experience, or to check something (i.e. research)?

 

With that said, I think the ship has sailed as far as ScummVM being a serious archival tool goes. It seems the only real avenue for that is using something like DOSBox, or another way of simulating the original runtime conditions, so that there is no interpretation or decision making happening.

 

BTW this wall of text isn’t meant to savage your contribution Thunderpeel. It is more a general concern I have about the scope and direction of ScummVM, which is admirably volunteer-run but also constitutes the only official way of playing a lot of games, and the primary way people play them unofficially.

[Jake]

6 hours ago, Thrik said:

BTW this wall of text isn’t meant to savage your contribution Thunderpeel.

Same! Not a personal jab, and as Thrik said, the idea that scummvm is an archival tool has been more or less put to rest at this point, but the general conversation it raises is interesting and one I care about.