[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