s-island

That's a great looking collector's edition! I signed up for Nintendo's developer program a while ago and I had to sign an NDA that prohibits me from disclosing details of their SDK and API. That'd crash with the GPL, which ScummVM is licensed under, since it requires any published modifications to ScummVM to also be released in source code form. Back in 2009, Atari tried anyway and there was much lawyering: http://sev-notes.blogspot.com/2009/06/gpl-scummvm-and-violations.html

The img files are images of the original floppy disks. They can be opened in DOSBox with the IMGMOUNT command. You can then install the games to your HD. Kryoflux images are a complete record of the magnetic field of the floppy disk platters. They can be used to create clones of the original disks with a Kryoflux device and floppy drive.

Back to finding the slides. He also sold the back cover art for MI2 and that seems to have vanished as well.

I hope it becomes a big enough success that they can do the sequel and properly finish it.

Yeah, that stuff is not a part of the scripts, but SPUTM itself.

Yeah, some Sierra games had far more timing-related bugs where they just ran too fast or stopped working on faster computers. I could never get past the start in Quest for Glory 4 when I bought the QfG collection back in the late 1990s. A sequence in Space Quest 4 ran too fast so it was impossible to survive. NewRisingSun made a bunch of patches for these games about 10-15 years ago, but they had to be applied manually so it's nice to see all that stuff integrated into ScummVM since it makes it easier for people to play these games.

The DVD version of WCIV was only available as a bundle with a Creative DVD-ROM drive that also came with an MPEG-2 decoder card to play back DVD video because CPUs were too slow do that back then. The game was tied to that card, but there have been fan-made patches that integrated a software decoder.

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.

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.

Several of the disks can be found in the collections on Web Archive as image files that you can mount in DOSBox.

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.

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.

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.

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.

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.