[Scummvm-devel] Possible new backend features
max at quendi.de
Tue Apr 4 17:45:24 CEST 2006
I want to get back to another point in Neil's post. This concerns in
particular also the WinCE and Symbian ports!
BTW, Neil, are you on scummvm-devel? I am not 100% sure which is why
I CC you.
Am 01.04.2006 um 19:47 schrieb Neil Millstone:
> I've also used ConfMan.get("gameid") to find out the id of the
> running game, removing my other hack to the main source tree.
Unfortunately, ConfMan.get("gameid") will not always work -- namely
when using the gameid as targetname, the gameid entry might not be
The WinCE and Symbian ports also use the gameid (until recently they
actually incorrectly used the target name), but they get it from the
GameDetector, which requires them to do various nasty hacks related
This clearly is bad!
> I look the string up in a table to set my controls to one of four
> modes that I have internally. I'm not sure if this could be done
> a more generic way that would be useful to other ports, but at
> least it doesn't require a hack in the ScummVM source. The control
> changes involve how the port handles the touch screen, so it's not
> really applicable to other ports (except perhaps Symbian or other
> ports that have touch screens, but I imaging they want to have
> their own way of solving these issues).
Well, I certainly would prefer a generic solution... i.e. I prefer
something like our "feature flags" that specifically describe
requirements/features, over hard coding a list of gameids. In
particular, it makes it easier to add more engines, w/o having to
update all the backends each time.
Still, we might need some time to come up with a sensible proposal
here (and it'll require the affected porters to tell us what they
need, precisely). Hence, for now I think we should use a pragmatic
soluion as a temporary remedy:
We can add a OSystem::setGameID(String) method, defaulting to do
nothing. We then call that in the appropriate spot in main.cpp,
namely right before the engine launches. We'll also call it with an
empty string after the engine quits, which should tell the backend to
"reset" the mapping (will be useful once we activate "return-to-
I consider this method a temporary measure and hope to eventually get
rid of it one day, but it would allow us to do various cleanups *now*.
What do you think?
More information about the Scummvm-devel