[Scummvm-devel] Dreamcast config file (Was: 0.7.0 release schedule)
Max Horn
max at quendi.de
Mon Dec 6 17:04:00 CET 2004
Am 06.12.2004 um 16:53 schrieb Marcus Comstedt:
[...]
> Also, there still seems to be no way of activating the aspect-ratio
> feature from the menus. Which means that there is no way to activate
> it at all on the Dreamcast (even though it is implemented) since there
> is no command line or settings file.
>
This reminds me about something I wanted to ask (might be relevant for
other porters, too): so, there is no config file on Dreamcast (I wasn't
sure about this, good to know it for sure now). Is this a fundamental
problem and impossible; or would it be an option to (ab)use a save slot
for such a thing? I am not talking about an ugly hack like using the
SaveGame manager, mind you; what I want to get at is this: would it be
helpful/desirable/possible to add some kind of abstraction for the
config file, which would allow alternative storage locations? Like,
something which would allow you to load&store config data from a VMU ?
If it is, we can pick one of multiple possibles that come to mind to
solve that, e.g.:
* add special (possible internal to the Dreamcast backend) subclass of
File which works similar to the SaveFile stuff (and maybe add a
File*OSystem::getConfigFile() method)
* I could finally implement my good old "NewFile" proposals ;-).
FileSystemNode already demonstrate some of the techniques for that
(like, how it tries to allow customization via subclassing, yet you can
still use FileSystemNodes as stack variables in your code w/o having to
worry about memory management; a feature we heavily rely upon)
* DirectoryIDs were suggested by Jerome, but I don't see how they solve
this particular problem (which doesn't mean they are a bad idea or
useless, not at all; I just think they'd probably be part of the above
"NewFile" stuff which we discussed in the past)
* a custom hack in the ConfigFileManager class
* I could also add a ConfigFile class, specifically made to be used for
ConfigFileManager; that class would simply expose key/secion access
methods; how it actually performs storage could be fully customized (so
besides the current .ini-style-"backend", we could also add an XML
format, Win registry access, VMU writing, OS X User Defaults, <insert
your favorite config file technology here>...)
Cheers,
Max
More information about the Scummvm-devel
mailing list