[Scummvm-devel] Game enhancements

yotam barnoy yotambarnoy at gmail.com
Fri Nov 5 12:24:41 CET 2010


I think we may want to decide on a mission statement for ScummVM to
prevent the sort of purist arguments we're having now. This should
probably be settled by our project leads, because otherwise there will
probably be no consensus.

My understanding of ScummVM's approach is that we're not just aiming
to reproduce the old game experience, though it is indeed one of our
goals. We also aim to provide a uniform experience across many
platforms and many engines (on games that originate in wildly
different platforms and eras), and this goal clashes with the desire
to reproduce every game faithfully. Yet another goal of ours is to
enhance the experience of playing the old games so that they can do
things that they couldn't do before, such as running without bugs,
using compressed files, looking better etc. Some of these
enhancements, such as bug fixes, are a given, as few purists would
want to make sure ScummVM recreates their favorite crash, while
others, such as undithering, belong more in the 'optional' category.

>From what I can tell, these 2 latter goals take precedence over the
first one. Therefore, investing time in recreating the original game
dialogs may be called for by the first goal, but the 2nd goal would
suggest that this is not a worthwhile use of development time as it
disturbs the uniform interface experience.

 Yotam


On Fri, Nov 5, 2010 at 11:50 AM, Max Horn <max at quendi.de> wrote:
>
> Am 05.11.2010 um 10:40 schrieb Max Horn:
>
>>
>> Am 05.11.2010 um 08:58 schrieb yotam barnoy:
>>
>>> If we're discussing dynamic game options in the GUI, we may also want
>>> to discuss dynamic backend options. Different backends have options
>>> that need to be set, and we only want to show the options for the
>>> current backend. I think we may want to solve these 2 problems at the
>>> same time.
>>
>> Sure. We have had this on our TODO for a long time, too. People are welcome to work on that.
>>
>> However, I think some planning would be due for this. To e.g. avoid introducing regressions, esp. in 320x200 mode. So that we avoid crashes like bug #3103351 caused by the new GUI option Filippos added. :)
>
> Ooops, re-reading what I wrote (I should have done that before pressing "send"), this does not convey what I want to say.
>
> First off, little regressions like that always can happen -- I merely wanted to stress that GUI changes need to be tested carefully with all kinds of scaler / aspect ratio combinations.
>
> Moreover, though, when adding new GUI elements, we should adjust SCUMMVM_THEME_VERSION_STR to avoid people accidentally using outdated theme files with their current ScummVM version. We've neglected that in the past a log, sadly; this would now be a good time to update that string, and keep updating it in the future.
>
> Lastly, the thing that we should *design* about the new engine/backends custom option is how engines/backends would signal what options to add, and where. Obviously, hard coding a long list would be possible, but undesirable.
>
> For the backends, a new OSystem APPI comes to mind as a possible way, which somehow would be allowed to insert extra items on a dedicated tab in the global options dialog. What I don't know right now is how to make this play nice with the theme code, though...
>
> For engines, the MetaEngine class seems to be the right place, as it is available from the launcher.
>
>
> Bye,
> Max
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>




More information about the Scummvm-devel mailing list