ScummVM “Interactive Fantasy” 2.2.0 Sees the Light
scummvm.org
scummvm.org
But 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.
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:
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.
various abandonware websites, just google it
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.