[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