Re: [tuxdroid-user] Tuxdroid gamepad interface

[David B. <da...@ja...>]

On Mon, 09 Apr 2007 19:26:15 +0200, Philippe Teuwen <ph...@te...>  
wrote:

> Florent THIERY wrote:
>> Sounds like a good idea to me !
>>
>> Add to this the possibility to use the IR transceiver as if it was
>> really on the host computer...
>>
>> But then there would be no need for the daemon anymore....
>>
> Using the joypad API won't help that much I think.
> We have many inputs, not just 4:
> - wings & head
> - light level
> - IR codes
> - future: battery level

I would also like to add the noise level, a kind of peak microphone level  
that can be used to detect handclaps or someone that shouts or simply  
differentiate silence from noise. You could also detect if you try to  
manually close the eyes when they're opened but that's not reliable. (the  
'eyes open' switch should be released but that's not sure it will be  
pushed again when you'll release the eyes)

> Some of those inputs are on events, some are on polling (which could be
> also on events if there is a trigger level in the firmware such as low
> batt warning)
>
> We have many outputs, more than what feedback joystick API could offer
> - eyes, mouth, wings, spin movements
> - eyes leds, IR led
>
> We have still the major issue to be dealt by a daemon: allowing multiple
> applications to interact with the Tux.
>
> And having a "false" joystick being the Tux could make strange thinks
> with games using automatically any found joystick...
>
> Phil
>
I guess Bruno wants this to interact with simple games like GCompris. If  
you only need a few buttons, why not. You could have 2 modes, one with the  
2 wings and head button, and anoher mode using the remote keys. Forcing  
the eyes should be used carefully (see above) and forcing anything else  
will not work because of the clutch (spin or wings) or will be difficult  
(beak). One could use the light sensor to detect when the hand covers the  
eyes for example, but you should take care of all different situations  
where the luminosity will vary.

There're different ways to get that funcitonality:
- a specific USB firmware that could be recognized as a joystick, seems  
hard to develop as you need some 8051 and USB knowledge and kysoh/c2me  
probably won't have the ressources to develop that atm;
- a virtual jostick driver, I guess this should be possible but I've no  
experience;
- using plugins and the api, which is what we want to do now as you can  
have much more than a joystick functionality but you will have to  
implement that for any application.

If the second option is easy to develop, why not. But is there many  
applications that will benefit from this? As we use the RF, there's a  
reaction time which is not negligible and will make mmost of the games  
unusable.

Jst my 2 cents
david