On 2000/Jan/04, Andreas Beck wrote:

> > > I know that I can access to event->any.origin to distingish between
> > > keyboard and joystick events, but how can I know which value is the keyboard
> > > one and which is the joystick one? In a few proofs that I've made the
> > > keyboard events had the 0100 value and the joystick the 0200, but I don't
> > > know if it is always this way.
> No, this is not guaranteed. You need to query the device capabilities, if
> you want to distinguish them. You could as well distinguish by the keys that
> get sent, but that's not "the nice way".

        I know. I can't do such thing in a library :)

> Wouter already answered, how the nicer way works.

        Thanks to both.

> If GGL can stand a bit of redesign in the input subsystem, I'd however
> suggest that you have a look at LibGIC. It enforces descent-style
> configurability for all game controls with little effort on the programmer
> side, which might be a nice thing to have ... :-).

        I couldn't find any document about libgic, I have a december cvs
snapshot and I could only see the includes, which didn't gave me much
information. Where can I find docs? I there aren't, could you give to me a
little explanation on what this extension is, please?
        Anyway, the GGL input system is really easy, we have only four kind
of events, the axis event, the button event, the collision event and the
finish event. Only the first two ones are really related to GII. And There
are four kind of devices (will be much more), the GglKeyDev, GglMouseDev,
GglJoyDev and GglArbiter. You can have as many instances of these devices as
you want, and it's possible and usual to have a GglKeyDev and a GglJoyDev
related to the same ggi_visual_t. I only need to filter events to receive at
the first one only keyboard events and at the second one only joystick
events. Hmm, I've found another problem, if I have two joysticks, when one
reads an event and it's not for it, the second one won't never receive this
event, maybe we should add an intermediate layer that processes ggi events
and allows other ways of filtering :(

        There is another concept on GGL, the Observer. An Observer can
receive events from any device, and a device can have a number of observers
attached to it.

        Can we take advantage from LibGIC without losing the concepts of
Device and Observer?

        I like very much to have different device objects because it allows
to add GGL new interesting capabilities by only adding more code (more
classes), or extending existent one (sub-classes) without touching existent
one at all. For example, I can add a joystick emulator that uses the
keyboard for those games that only need the axis sense, and not the integer
value. It would be a subclass of GglJoyDev.

In the beggining, Turing created the machine...
 /_) \/ / /  email: mailto:[EMAIL PROTECTED]
/ \  / (_/   www  : http://programacion.mundivia.es/ryu
[ GGL developer ] & [ IRCore developer ] & [ GPUL member ]

Reply via email to