3 ms·

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://wi

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.

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.