[Scummvm-devel] Release 1.3.0 status -- 2010-04-24

Max Horn max at quendi.de
Tue May 24 14:35:44 CEST 2011

Am 24.05.2011 um 14:20 schrieb Frantisek Dufka:

> On 24.5.2011 13:01, Max Horn wrote:
>> 1) Create a proper maemo backend derived from the SDL backend. With the new modularization stuff, this should be fairly straight forward. A matter of a couple hours, I think. Plus testing, though.
> Yes, I should get myself updated with the new modularization code and then it is easy :-)


>> 3) The configure script changes have luckily shrunk to only one change: libdir is being twiddled with:
>> -libdir='${exec_prefix}/lib'
>> +libdir='${exec_prefix}/lib/scummvm'
>> and later
>> -               DEFINES="$DEFINES -DPLUGIN_DIRECTORY=\\\"$libdir/scummvm\\\""
>> +               DEFINES="$DEFINES -DPLUGIN_DIRECTORY=\\\"$libdir\\\""
>> To be honest, I forgot what that was about, could you remind me? It seems like a "do nothing" change, unless somebody wants to use the --libdir option. Well, in that case, just do the same thing as the WebOS port, that is:


> Yes, that's the reason, I don't want to have /opt/scummvm/lib/scummvm inside /opt/scummvm when I specify --libdir=/opt/scummvm/lib
> /opt/{package} is default Maemo 5 location as a workaround to limitation of N900 flash based storage.
> IMO my configure patch should be commited for all unless it breaks something since when I specify --libdir I really mean it! I hate when current scummvm configure decides to add /scummvm even if I explicitly said what I want libdir to be.
> And as you said, when no --libdir is specified there is no change.

Actually, there is a change: For the WebOS port, the wrong libdir would then be used by default, so the webos port would have to always manually specify a custom libdir... or do some other trickery...

Alas, in principle, I'd be fine with the change you propose. But *not* for 1.3.0, it's way too late for such a behavior change there. But we can look into it for 1.4.0git. But *please* after my configure changes on trunk have landed, I don't want to redo them yet again ;).


>> Maybe this could also be solved using the keymapper, though I am not sure how well that works these days...
> IMO engines should be rewritten to not to use real keycodes but some symbolic actions (i.e. KEY_INGAME_MENU instead of KEYCODE_F8).

Yes, this has been proposed and discussed by me. In fact *I* proposed it at least once, too, and even sketched some ideas for it. The problem is, it's very easy to say "all engines should be changed", and tremendously hard to actually modify all engines *and* all backends, *and* to also properly design and implement the relevant code infrastructure. You are most welcome to pursue this project, though, it's been high on my wish list for years :).

> Then the keymapper should set the real mapping. I haven't checked current keymapper code but I am not sure how it could work when engines still use real keycodes and sometimes same keycode have different meaning in same engine depending on current engine state (ie game area vs engine in-game menu). I think in Maemo patch there is at least one place where the mapping is different for same keycode depending on engine state.
>> Unless you plan to drop support for Maemo<  5 right away, *and* also know for sure that you'll have the time to write a completely new backend from scratch, I'd say it's definitely worth to spend the couple hours necessary to turn the patch into a proper backend :).
> The easiest for me is to continue with the SDL patch until Maemo 4 or 5 finally dies but I'll see how easy is to minimize current patch with the new modularized SDL backend code.
> In longer term it would be nice if some new QT/OpenGL ES based backend appeared and made my code obsolete :-)

Yeah, sure, and I want a unicorn ;). 

> Actually I no longer use Maemo devices regularly (got Openpandora console and Nook Color Android tablet, both are possibly better for ScummVM gaming than Maemo devices). Also I didn't have time to play any ScummVM game myself on any platform in last two years or so (except testing for scummvm releases) due to real life, so the motivation for big changes in Maemo ScummVM backend is currently not very high :-)

Perfectly understandable. However, this makes me wonder whether it makes sense to even attempt to offer an "official" Maemor port. It seems your port is doing quite well outside the ScummVM tree, and neither your port nor ScummVM benefit from having the patch inside our repository.

So from my point of view, there are two possible ways to proceed:

1) We (well, you ;) turn the backend into one that is properly contained in our code, as discussed above.

2) We abandon this port as an official one, removing any traces from it from our codebase. Of course, we could and should still refer and link to it from our homepage. Just not as an official port, as that would reflect reality much better.

Don't get me wrong: This is *not* a threat or anything like that, I am just honestly expressing how the matter looks to me. No grudge or bad feeling whatsoever :)


More information about the Scummvm-devel mailing list