[Scummvm-devel] Release 1.3.0 status -- 2010-04-24
Frantisek Dufka
dufkaf at gmail.com
Tue May 24 14:20:49 CEST 2011
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:
>
> --- a/configure
> +++ b/configure
> @@ -2973,7 +2973,7 @@ case $_backend in
> # Add ../plugins as a path so plugins can be found when running from a .PND.
> DEFINES="$DEFINES -DPLUGIN_DIRECTORY=\\\"../plugins\\\""
> ;;
> - webos)
> + maemo | webos)
> # The WebOS app wants the plugins in the "lib" directory
> # without a scummvm sub directory.
> DEFINES="$DEFINES -DPLUGIN_DIRECTORY=\\\"$libdir\\\""
>
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.
> 4) This leaves a bunch of engine changes. Not sure how current these are. They mostly tweak engine controls. This *is* problematic, but on the other hand, it touches code that changes much less frequently. So we could keep it in a patch. Or bite the bullet and just commit that part, although with big "FIXME" comments added to each modification, and a brief explanation why it's there.
>
They are current. Those are just the ones I personally tested with games
I played. These bits are the main reason for having the patch. Unless
this gets resolved it does not solve the issue with the patch completely
so there is less motivation to do the other stuff when the fragile part
still remains.
> 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). 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 :-)
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 :-)
Frantisek
More information about the Scummvm-devel
mailing list