As well as esoteric historic operating systems like AmigaOS and RISC OS, there are even builds for historical consoles like the Dreamcast. It's amazing.
In my opinion, this is not actually a good thing. It creates an unhealthy focus on how many ports there are rather than putting the focus on the preservation of games and the quality of the user experience.
Most of these esoteric ports can only be compiled by custom ancient GCC binaries whose original source code is either lost to time or won’t compile on a contemporary compiler or CPU, and nobody actually uses them. I ran analytics on web logs during the month after the ScummVM 2.0 release, and the Dreamcast port you mentioned accounted for 4[0] of 16,068 downloads.
I would, furthermore, argue that this leads to less portable code in the long run since these old ports force the project to be stuck using C++98, so there’s a whole bunch of undefined behaviour, race conditions, and other garbage code in ScummVM which compromises future compatibility and wouldn’t be possible if unsafe coding practices from the bad old days were prohibited.
Source: I was once a major contributor to ScummVM and tried unsuccessfully to fix this.
[0] It’s a little hard to get an exact number since the port is split into several files; the most downloaded Dreamcast file had 16 downloads and the least downloaded 4, after excluding people who were just batch downloading the whole directory of installers. I use the lowest number since there’s no reason to think that someone would only intend to use engines starting with the letters A–G more than they would intend to use engines starting with the letters O–S, especially since the banner release in 2.0 was the SCI32 engine, and that was the one with 4 downloads.
Even the Dreamcast port has a version of GCC able to pass the initial standards tests, so most legacy ports seem to be in a state that they'll be able to leverage at least a subset of C++11 functionality.
(Sadly - as with many large community-driven projects that require a specialist set of skills like reverse engineering - ScummVM does have a slight history of alienating contributors only to adopt the point in contention as some point in the future.
Source: I was once a co-lead developer for ScummVM, and tried unsuccessfully to fix this :P)
Hi buddy. Thanks for taking the time to create an account on HN to reply to me. You should maybe also reply to my emails. :-)
Any step forward here is good, but the main problem remains: the number of ports takes precedence over basically any other consideration by some long-time members (including the DFL), and the project suffers. You can see some of this madness laid out in the page you linked:
1. Testing subsets of C++11 on platforms that no users actually use (again, I did the analysis and presented the data in 2017);
2. Testing compilers for ports that are already dead and have had no new ScummVM releases since 2015;
3. Testing for C++11 features on unsalvageable binary-only compilers from 2003.
I actually did a whole lot of work to try to bridge the gap and satisfy everyone. I rewrote the CI system, created about a dozen Docker images with up-to-date compilers, and modified the `configure` script so that individual engines could opt in to using newer language features while old engines and backends could continue to build so people could keep their ‘trophy’ ports. I proposed a new release policy where builds would be automated (instead of the current situation where random people are individually responsible for manually creating and uploading binaries), and it would be the responsibility of porters to make Docker images with functioning build environments to hook into the new build system. This all seemed very rational and would’ve solved a lot of problems, but it never happened, at least in part because the guy who does nothing except build the Dreamcast binaries refuses to own an x86 computer because he thinks the ISA sucks and so would have had some trouble making the image to automate the build.
Obviously any passion project run by volunteers doesn’t have to follow trends or even care what their users think, but it’s clear that ScummVM holds a unique and important place in software preservation, so merits a little more care and thoughtful stewardship. I think that it (and its users) deserve more than they get when folks hold up “number of ports” as a critical metric and then use it to block important changes that would significantly improve the project in every other way.
As a user, I really admire and appreciate the work that goes into ScummVM to preserve old games. I also love reading the development blog. I have a number of old computers with old OSes in them, such as Win98, XP, and Mac OS X 10.4 and 10.5 on PowerPC. I can’t speak for all the esoteric porting, but it makes me happy to be able to install software that’s in active development on old hardware, and that can even improve the playing experience compared to the original game engines. Thanks for all your work.
Yes!! I've been wanting to play Ultima 4 for a long time. But when MacOS stopped supporting 32 bit, the Dos VM I had broke. Now I can finally play it again!
Yeah, for anything DOS based, I imagine dosbox is a better solution. It's how gog.com provides those older games when you buy them, and they have to support them.
Sorry, I actually knew that and forgot. I didn't actually mean to imply dosbox was better than ScummVM for DOS games, just that it's probably better than a full VM when it works. ScummVM is probably as good or even better than dosbox for the things it supports well, so would probably be better than a VM too.
I have played Monkey Island 1 on a twenty year old Navman N20 gps. It was a very fun excercise to get ScummVM working on that old Windows CE system and use its stylus to navigate Guybrush around. :)
I had no idea ScummVM supported so many games and engines! I only knew it as the LucasArts games and what I assumed would be homebrew games using the same engine. If you were like me, check it out and play a really great variety of games!
Most of the games ScummVM supports are abandonware at this point, so there's no legal way to buy them apart from digging up used copies. Otherwise, as with most abandonware, they can be found floating around the internet.
Holy shit it now supports basically every text adventure ever:
ADRIFT (except for version 5)
AdvSys
AGT
Alan 2 & 3
Archetype (newly reimplemented for Glk from the original Pascal sources)
Hugo
JACL
Level 9
Magnetic Scrolls
Quest
Scott Adams
ZCode (all ZCode games except the Infocom graphical version 6 games).
Currently, more than 1600 games are detected and supported.
----
The only notable text adventure interpreter I can think of offhand that's not on this list is The Quill.
Testing it out though, I think it's got a few versions to go before it'll replace more focused interpreters - it won't load any zcode games distributed in the modern '.gblorb' format, and the decision to render all the text as white on searing blue, at 640x480, is... well, it sure is an accurate emulation of the experience of playing a text adventure back in the nineties, I'll give it that. Still, the breadth of support is super impressive!
> - it won't load any zcode games distributed in the modern '.gblorb' format,
That's Glulxe, not ZCode. It's the z-machine extended for 32 bit.
>640x480, is... well, it sure is an accurate emulation of the experience of playing a text adventure
Not so much, every interpreter in the 90's could change the colours perfectly. Also, the resolution didn't matter, as every game was tought for an 80x24 terminal.
Frotz for DOS had color switches so you could use a b/w setup perfectly.
I am mostly comparing the experience ScummVM offers for a text game to what something like Lectrote offers: a window sitting in your operating system, with text rendered at the native resolution of your screen by the OS's text system, versus a bunch of text routines spewing a 1-bit unantialiased font directly into an unresizable frame-buffer designed around upscaling graphical games of the nineties to modern screens.
Lectrote works on top of Chromium/Electron and thus leaves a lot to be desired. At least for macOS, there's no reason to compromise in this way when there exist interpreters that take full advantage of the system.
Spatterlight is a native Cocoa application with superior typography, better performance and orders of magnitude less bloat:
Besides using 6x more memory (close to 500MB for my target game) and taking 3x to load, latency is noticeably worse to the point of it becoming a major annoyance during play.
Typing feels sluggish and there's obvious delay after hitting ENTER and waiting for input to be processed and results to be displayed.
Spatterlight feels instant.
Are these annoyances academic? Not for me.
Notable missing text adventure interpreter: TADS. I'm guessing this is a licensing issue, because the only Free Software implementation is GPL3 (QTads), and ScummVM is GPL2 or later.
Glulx (used for modern versions of Inform) isn't listed in the release notes, but there's Glulx code in the source anyway.
Wow. I had no idea ScummVM supported so many platforms. I thought it was just for old-school LucasArts games. Seeing "Eye of the Beholder -- Sega CD version" made me blink a couple times and says "huh, cool." out loud.
Everybody needs to try King's Quest, Maniac Mansion/Day of the Tentacle, Monkey Island 1/2, and Indiana Jones: Fate of Atlantis at least once in their lives.
(I still can't beleive the levels of stupitidy this universe must have for Lucasfilm to not have made an Indy movie about Atlantis, instead of that crystal skull crap)
Perhaps because Harrison Ford was too old to possibly reprise a Fate of Atlantis Indy? Fate of Atlantis is set only three years after Raiders of the Lost Ark
I'm sure retconning (was the game even canon?) it as having happened after Crusade would have taken less work than writing an entire new story.. (though considering the quality of Skull's writing, I'm not sure)
Even more, the ultimate geek will run those Sierra and Lucasarts games on ScummVM (or DOSBox) using Roland MT-32 emulation for enhanced music! (research on forums or Youtube). Pretty neat
One of the best things about gaming in that era was how you essentially got multiple remixes/covers for every piece of music, depending on the hardware you ran it on.
For some games, I prefer the Amiga music, for others PC/Roland, or even PC/Adlib if that was what I first grew up with.
52 comments
[ 2.9 ms ] story [ 50.9 ms ] threadBut surely ScummVM must be gunning for fifth place. The number of platforms with a build available on the Downloads page is genuinely impressive:
https://www.scummvm.org/downloads/
As well as esoteric historic operating systems like AmigaOS and RISC OS, there are even builds for historical consoles like the Dreamcast. It's amazing.
No. The Z-Machine itself in ScummVM has been ported even to pens and the TOPS-20 based KA-10.
Most of these esoteric ports can only be compiled by custom ancient GCC binaries whose original source code is either lost to time or won’t compile on a contemporary compiler or CPU, and nobody actually uses them. I ran analytics on web logs during the month after the ScummVM 2.0 release, and the Dreamcast port you mentioned accounted for 4[0] of 16,068 downloads.
I would, furthermore, argue that this leads to less portable code in the long run since these old ports force the project to be stuck using C++98, so there’s a whole bunch of undefined behaviour, race conditions, and other garbage code in ScummVM which compromises future compatibility and wouldn’t be possible if unsafe coding practices from the bad old days were prohibited.
Source: I was once a major contributor to ScummVM and tried unsuccessfully to fix this.
[0] It’s a little hard to get an exact number since the port is split into several files; the most downloaded Dreamcast file had 16 downloads and the least downloaded 4, after excluding people who were just batch downloading the whole directory of installers. I use the lowest number since there’s no reason to think that someone would only intend to use engines starting with the letters A–G more than they would intend to use engines starting with the letters O–S, especially since the banner release in 2.0 was the SCI32 engine, and that was the one with 4 downloads.
Believe it or not, there's finally some progress here!
https://wiki.scummvm.org/index.php?title=Compiling_ScummVM/C...
Even the Dreamcast port has a version of GCC able to pass the initial standards tests, so most legacy ports seem to be in a state that they'll be able to leverage at least a subset of C++11 functionality.
(Sadly - as with many large community-driven projects that require a specialist set of skills like reverse engineering - ScummVM does have a slight history of alienating contributors only to adopt the point in contention as some point in the future.
Source: I was once a co-lead developer for ScummVM, and tried unsuccessfully to fix this :P)
Any step forward here is good, but the main problem remains: the number of ports takes precedence over basically any other consideration by some long-time members (including the DFL), and the project suffers. You can see some of this madness laid out in the page you linked:
1. Testing subsets of C++11 on platforms that no users actually use (again, I did the analysis and presented the data in 2017);
2. Testing compilers for ports that are already dead and have had no new ScummVM releases since 2015;
3. Testing for C++11 features on unsalvageable binary-only compilers from 2003.
I actually did a whole lot of work to try to bridge the gap and satisfy everyone. I rewrote the CI system, created about a dozen Docker images with up-to-date compilers, and modified the `configure` script so that individual engines could opt in to using newer language features while old engines and backends could continue to build so people could keep their ‘trophy’ ports. I proposed a new release policy where builds would be automated (instead of the current situation where random people are individually responsible for manually creating and uploading binaries), and it would be the responsibility of porters to make Docker images with functioning build environments to hook into the new build system. This all seemed very rational and would’ve solved a lot of problems, but it never happened, at least in part because the guy who does nothing except build the Dreamcast binaries refuses to own an x86 computer because he thinks the ISA sucks and so would have had some trouble making the image to automate the build.
Obviously any passion project run by volunteers doesn’t have to follow trends or even care what their users think, but it’s clear that ScummVM holds a unique and important place in software preservation, so merits a little more care and thoughtful stewardship. I think that it (and its users) deserve more than they get when folks hold up “number of ports” as a critical metric and then use it to block important changes that would significantly improve the project in every other way.
https://pkgsrc.joyent.com/install-on-osx/
I could never get DOSBox working on 64 with with ultima 4.
Playing Quest for Glory on the Oculus Quest is pretty fun, but I think the PS Vita might have been my favorite ScummVM device.
various abandonware websites, just google it
ADRIFT (except for version 5)
AdvSys
AGT
Alan 2 & 3
Archetype (newly reimplemented for Glk from the original Pascal sources)
Hugo
JACL
Level 9
Magnetic Scrolls
Quest
Scott Adams
ZCode (all ZCode games except the Infocom graphical version 6 games).
Currently, more than 1600 games are detected and supported.
----
The only notable text adventure interpreter I can think of offhand that's not on this list is The Quill.
Testing it out though, I think it's got a few versions to go before it'll replace more focused interpreters - it won't load any zcode games distributed in the modern '.gblorb' format, and the decision to render all the text as white on searing blue, at 640x480, is... well, it sure is an accurate emulation of the experience of playing a text adventure back in the nineties, I'll give it that. Still, the breadth of support is super impressive!
That's Glulxe, not ZCode. It's the z-machine extended for 32 bit.
>640x480, is... well, it sure is an accurate emulation of the experience of playing a text adventure
Not so much, every interpreter in the 90's could change the colours perfectly. Also, the resolution didn't matter, as every game was tought for an 80x24 terminal.
Frotz for DOS had color switches so you could use a b/w setup perfectly.
For instance, here is the first screenful of Plotkin's So Far in ScummVM 2.2.0 and Lectrote 1.3.4: https://egypt.urnash.com/media/blogs.dir/1/files/2020/09/So-...
Spatterlight is a native Cocoa application with superior typography, better performance and orders of magnitude less bloat:
http://ccxvii.net/spatterlight/
And for Magnetic Scrolls games, there's the amazing magnetiX:
http://maczentrisch.de/magnetiX/
Typing feels sluggish and there's obvious delay after hitting ENTER and waiting for input to be processed and results to be displayed.
Spatterlight feels instant. Are these annoyances academic? Not for me.
You could disable the blue background in frotz under DOS,
and in the 90's everyone had Winfrotz available.
On Linux, XTerm/RXVT/ATerm with every font/colour or the bare tty running frotz too, far more readable than that eye soring blue.
Glulx (used for modern versions of Inform) isn't listed in the release notes, but there's Glulx code in the source anyway.
(I still can't beleive the levels of stupitidy this universe must have for Lucasfilm to not have made an Indy movie about Atlantis, instead of that crystal skull crap)
For some games, I prefer the Amiga music, for others PC/Roland, or even PC/Adlib if that was what I first grew up with.