[Scummvm-devel] Joystick code

Max Horn max at quendi.de
Wed Sep 10 03:38:06 CEST 2003


Am Mittwoch, 10.09.03 um 12:13 Uhr schrieb Jonathan Gray:

>
>
> On Wed, 10 Sep 2003, Max Horn wrote:
>
>> Yo folks,
>>
>> I wonder if we should disable the joystick code in the SDL backend, or
>> at the very least, turn it off by default and provide a command line
>> (and config file) option to enable it. Rationale: lots of problems are
>> caused by it, at least on Windows, including crashes, stuck mouse
>> cursor, "wandering" mouse cursor etc. OTOH, I am aware of anybody
>> actually using it. Of course that doesn't mean you, dear joystick
>> users, aren't out there, which is why making this an option would be
>> preferable (although slightly more work).
>
> Surely you meant to say "I am _not_ aware" above...
Right :-)

> I started adding a -jx where x is the joystick number option to my 
> local
> src but didn't manage to track down some really strange segfault I 
> think
> was happening in glibc.
>
> Anyway I'd prefer is the keyboard mouse/joystick control happens at a
> level above the backends. Things like button mapping for a joystick and
> which keys to steal for keyboard navigation if any are rather engine
> specific things for example.
>
The question is: how to do that, exactly. One way would be to add an 
event type for joysticks, and remove any "keyboard-mouse" handling code 
from backends (do any backends besides the SDL backend do that 
anyway?). Of course then that would force any even loop which "wants" 
to support this to duplicate the joystick/keyboard handling code. A way 
to solve that would be to add a shared function which takes an event 
and "converts" it to a different event. And/or we could put an 
additional layer between the OSystem backend and the client code - e.g. 
by providing a wrapper around poll_event. Would be rather trivial.

On the long run I'd like to change the way we do event handling anyway. 
Instead of letting each code busy wait the poll_event method, it would 
be much nicer to start using "event run loops", and use a callback 
based mechanism. This has various advantages. The main problem of 
course is that the busy-waiting even loops do other things, too (like 
giving time to the game engines to do their work). That could be solved 
by special "IDLE" events... all this is still pretty rough, before I 
want to tackle it I'd rather move along with the plugin/module work I 
started recently :-)


Max







More information about the Scummvm-devel mailing list