adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] Engine Configuration


From: Kai Sterker
Subject: [Adonthell-devel] Engine Configuration
Date: Mon, 3 Jul 2006 10:03:25 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]