[Scummvm-devel] Game enhancements

[Max Horn]

Hi there,

Yotam summarizes the conflicting interests quite well, I think.

From my point of view ScummVM is meant to allow people to have fun playing certain vintage games across a wide variety of platforms.

100% accuracy is an ideal one can strive to reach, but like with most ideals, you should be careful to not exaggerate this to the utmost limits -- other interests simply conflict, and you need to make good compromises.

I'd like to illustrate what I mean with two concrete examples that were brought up in this discussion: The SCI undithering code, and the SCUMM save/load dialog:

The SCUMM save/load dialogs are not faithful to the original.
if you consider a perfect accurate, faithful-to-the-original play experience the ultimate goal, then one should try to replicate the original dialogs to the last bit. But if you scale that idealistic point of view just a little bit, and consider the following facts, you may change your point of view:

1) The original save/load dialogs in those games were very limited in functionality, in way that one can objectively describe. E.g. the number of save slots was highly limited, no thumbnails for the saves or other meta data, description string severely limited, etc.

2) People spend 99+% of their time playing the games, and (hopefully, at least; if not we did something wrong) less than 1% in the save/load dialog.  Indeed, I'd argue that our improvements (hotkeys for save/load, loading from launcher, improved save/load dialog which thanks to meta data allows you to identify the correct savestate much quicker)  allows people to cut down the time they have to spend in the save/load dialog for those old games. So that they can focus on what in my eyes is the primary purpose of ScummVM: Allowing people to *play* those games and have fun.

3) As they were hardcoded in C, re-implementing them would require a lot of dedicated RE work for every single affected game (it might be possible to write a single set of code which does it, with some tweaks to adjust it for the various games, but one would still have to checkout the disasm of every single .exe involved).
This is a lot of effort, esp. in view of points 1&2.

Based on that, it seems sensible to me to ignore the original hard coded save/load dialogs, rely on our custom dialogs, and focus our energies on improving the overall experience ScummVM provides.


Contrast this with the SCI undithering mode. 

1) The original graphics may or may not have been something that the authors intended this way or not. People may or may not prefer the undithered mode, this is highly subjective. I think the undithering is cool, but I also can understand people who prefer to have the original experience.

2) People spend 99+% of their time playing the games. During all that time, they have to look at the game graphics. A change which affects a lot of them hence affects people in a major way. It affects  what in my eyes is the primary purpose of ScummVM: Allowing people to *play* those games and have fun.

3) Implementing dithered mode is 0 work, as this is how the original game works. Implementing *undithering* however is quite some work (a cool & impressive technical feat).


Hence, allowing people to play both in dithered (original) and undithered (custom) mode seems like a no-brainer to me. Just like we offer multiple scalers. And totally unlike the custom save/load dialogs in SCUMM, which are a totally different story.



Bye,
Max