For my character schedule test script, I wanted to use the mapped controls, to test whether those work as well. Since those need to be configured somehow, I thought about a way to pass the engine configuration to the different modules. I'm not finished completely and code isn't committed yet, but I wanted to make you aware of the stuff (since the audio module for example contains a couple of TODOs that concern configuration.)
Basically, each of the input, gfx and audio modules have an additional setup() function, which is called by adonthell::init_modules() before calling the module's init() function. It gets a reference to the parsed configuration file and should do the following: [1] Read required values from configuration and store them somewhere so they can be accessed when initializing the backend. (An alternative might be to keep a reference to the complete configuration, especially if it might contain options that are specific to a certain backend only) [2] Create missing configuration options with a sensible default value (so that the engine will function even if no config file is present. That would be the case when the engine is started for the first time. Once missing options are put into the configuration in memory, they will be written to disk once the engine shuts down). [3] Add meta-information to the each configuration option, so that a configuration screen can display them properly. See http://adonthell.berlios.de/api/db/d30/classbase_1_1configuration.html#_details There are a few more things to consider when it comes to configuration stuff: * When changing config settings in-game, we'll might have to unload and restart some modules for changes to take effect. Audio and gfx comes to my mind here. Apart from providing this functionality, we'll have to see whether that works flawlessly or not. In the worst case, some changes cannot take effect unless the game is restarted. * If we want to allow to change the language in-game, we'll have to collect a list of available translations, preferably at runtime. Guess we can look into the locale folder and see what is there. This needs to be added to the NLS class. Not sure if there is a nice way to 'translate' something like de_DE into the proper language name. I wouldn't want to hardcode available languages somewhere, however, as that makes adding new translations more difficult. Might be a few more things I missed (for example, not all modules have a setup yet, since they probably won't need it), but it's another little step towards a functional engine :-). Comments? Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel