[Scummvm-devel] Possible new backend features
John.Willis at Distant-Earth.com
Sun Jan 29 10:56:02 CET 2006
>I have used ScummVM for years on the PC and have found it an amazing
>program. This is why it was my first choice for something to port to
>the DS. It's a great fit for the DS and it brings the games to life
>again. They look amazingly crisp on the DS's low res screen.
I can attest to that, the look of the VGA resolution games on a nice little
LCD is very pleasing. It was one of the reasons I started hacking with
ScummVM back in the GBA/GP32 days and the main reason I still hack on it
>I have been in contact with sev about getting it into CVS, but currently
>there are several hooks and additions to ScummVM which would need adding
>in a non-port-specific way. I am told this is the best place to suggest
Yep, devel, IRC and the WiKi seem like the ideal places to bring this
subject back up. It seems an ever more pertinent subject now that ScummVM
has several official small device backends and a handful of unofficial ones
and as small devices get ever more powerful I can only see this number
>1) The backend needs to know the GameID of the game that is running.
>I have different interfaces and tweaks for various games to make them
>nice and usable with the 'pen and buttons' interface, and I need to know
>which game is running to enable the necessary tweak. All that would be
>needed for this is a setGameID() function in OSystem.
Agreed, this was always a problem with the GP32 and is still a problem on
the GP2X. A long time ago I used to use several very nasty hacks to bubble
up the game ID to the backend. These days I just live without it (and lots
of notes about it on my TODO lists).
I would be more inclined to think that a better approach may be to bubble
'features' up to the backend for a given game (not really given this all
that much brain time mind you) but I still think being able to query
something to get the running game ID would be a huge plus. Especially when
you have a limited amount of inputs and you want to dynamically remap based
on the game (or even section of game). It is also handy (and I know I will
go to hell for this ;-)) if you need to make a specific evil hack for a game
on a specific device.
>2) The backend needs to be notified where the current speaking
>character is located. I have a zoomed-in view on the top screen and it
>uses pan-and-scan to move around to show the person who's speaking. It
>works pretty well with the simple hack I implemented. This could be
>implemented for all engines (I assume).
Well the 1st thing I intend to do after I write this is look into your hack
The GP2X implements the 640*480 games using it's hardware scalar (down to
320*240) but I have been toying with the idea of doing something very much
like this to allow the user to swap on the fly to a 320*240 panned view
centred on the users (or better still talking) character. I guess if this
was standardised whatever was built could just be empty unless the backend
wanted to do something with it.
This strikes me as a prime candidate to add in to the
>3) I have added several check boxes to two dialogs. These are a left
>handed option which swaps controls over for those holding the stylus in
>their left hand, and an indy fight controls option, which replaces the
>key mappings on the D-pad to those keys used for fighting in Indiana
>Jones. The two dialogs these appear on are the main options dialog you
>get to from the launcher, and the other is the in-game options dialog.
>It would be handy if there was an extra tab to the dialogs that was
>port-specific, and the backend could add gui controls to it.
Ok, I read that as extending the GUI in a clean way for port specific
functions. I am all for that, in order to avoid too much GUI hacking the
GP32 runs a hacky pre-launcher setup menu, as does the GP2X to set things
that could really be set in the GUI with some work (CPU speed, backlight,
custom port options like scalar, that sort of thing). With the new GUI work
going into CVS now seems like a good time to think about this.
A way to extend the in-game menu would also be nice (well for SCUMM games).
I can think of a few uses for that including your ideas for Indy3/4. I
assume your Indy hacks work a bit like this? i.e. in a fight, bring up the
menu, swap controls on the fly, end fight, revert to normal. That, I assume,
is one of the reasons you want the game ID bubbled up?
>4) The Scumm help screen shows PC keybaord controls, which are
>obviously not accurate on other ports without a keyboard. Perhaps it
>could be possible to send new text to the help dialog? Not essential
>though, as there are other ways round it.
A clean way for a backend to overload the help dialogs would be very nice to
have. I did start to look into this but gave up as none of the users of the
GP32 or more recently the GP2X ports ever seemed to click help before
mailing me or posting on forums anyway ;-). I just have some local nasty
#IFDEF patches at the moment.
>So, any thoughts on how likely some of these changes are? Or perhaps
>another way of doing this stuff that doesn't require changing ScummVM?
The bulk of these ideas seem sane and speaking as a fellow unofficial porter
I can see uses for some of them in my ports.
It does seem to muddy the clean separation from frontend to backend a little
but like all things in life theory tends to have a huge degree of
flexibility and compromise slapped on top before it becomes practice ;-).
I would be very interested to see what the official porters make of your
comments as I can see some of this being usable in other ports, a number of
your needs/ideas seem to be a very nice fit for the small devices discussion
More information about the Scummvm-devel