5 ms·

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

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.

Enderboi 6y ago
Snover! LTNS! Believe it or not, there's finally some progress here! https://wiki.scummvm.org/index.php?title=Compiling_ScummVM/C%2B%2B11_Readiness 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)
- csnover 6y ago
  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.
  - Match451 6y ago
    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.

Enderboi 6y ago

Snover! LTNS! Believe it or not, there's finally some progress here! https://wiki.scummvm.org/index.php?title=Compiling_ScummVM/C%2B%2B11_Readiness 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)

csnover 6y ago
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.
- Match451 6y ago
  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.