Re: Keyboard vs Joystick buttons
Hi ! suggest that you have a look at LibGIC. It enforces descent-style 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? The demos should pretty much explain what you need to know from the user perspective. But you are right - I should write some docs. I there aren't, could you give to me a little explanation on what this extension is, please? It is basically a trainable event mapper. You register the "program events" (like turn left, activate menu, shoot) with it, and it will establish a mapping between the program events and GII events. It contains a generic training system that allows to have Descent style "trainable input" with almost no effort. 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. Yes. The idea of LibGIC is to abstract the application events from the IO events. This allows to take care for unforeseen situations in the intermediate LibGIC layer. For example, some Joysticks send hatswitch events by moving the 4th axis to 5 distinct points. Many trainable games cannot cope with that, as they expect the hatswitch to work as multi-button-press. Using LibGIC this problem can easily be solved by inserting an additional recognizer library into the LibGIC config files. Same goes for say voice-recognition. event, maybe we should add an intermediate layer that processes ggi events and allows other ways of filtering :( You probably know, that LibGII features filters - do you ? The mouse filter is an example, that can accelerate and remap mouse actions. Can we take advantage from LibGIC without losing the concepts of Device and Observer? Not really. LibGIC abstracts the "Device" aspect entirely. 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. Using LibGII, this can already be done using filters, or with LibGIC, it is just a matter of training the game function. CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED]
Re: Keyboard vs Joystick buttons
On 2000/Jan/04, [EMAIL PROTECTED] wrote: Before all, I must say that I've understood much more seeing the gic.h include file than seeing the demos. little explanation on what this extension is, please? It is basically a trainable event mapper. You register the "program events" (like turn left, activate menu, shoot) with it, and it will establish a mapping between the program events and GII events. I've seen the examples and it seems a great idea, and of course it should save a lot of work to GGL and the users of GGL. But I have a few comments and questions (maybe you could start a FAQ with them) * If I understood well, control - context - head make a tree in a very ugly way. They have exactly the same methods, but Context is a high level in a tree over Control. And Head has less methods, but has basically the same relationship with context that context has with control. Aren't there cleaner ways of making trees? :) I think that it would be better if you remove Control, Context and Head, and create a tree, for example, something like this: gicTreeAllocate gicTreeFree gicTreeAttachFeature gicTreeDetachFeature gicTreeAttachTree gicTreeDetachTree [...] What do you think? * What are the S and L that you put in the recognizers (in the config files)? And how can I figure out which value should I put at the righ side of these strings? * It seems that LibGIC can wait a gii event and attach it to an action, but with very smooth movements of my joystick, it sends lots of events to GGI. Is there any way of saying LibGIC that is should only take into accound the significant movements of the axis? PS: I could make standard debian packages of LibGIC to install in my system without _any_ problem, and it is still version 0.1, it was incredible! :) -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
Keyboard vs Joystick buttons
I'm giving Joystick support to GGL, and it's almost done, but I found a little problem. The joystick buttons are reported in a evKey event, so, the GGL keyboard device gets its own events and also the joystick ones... I open the joystick by opening a gii_input_t of type "linux-joy", and then calling ggiJoinInputs with the ggi_visual_t and the new gii_input_t. 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. Can anybody help me, please? -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
Re: Keyboard vs Joystick buttons
Rubén wrote:
I'm giving Joystick support to GGL, and it's almost done, but I
found a little problem. The joystick buttons are reported in a evKey event,
so, the GGL keyboard device gets its own events and also the joystick
ones...
I open the joystick by opening a gii_input_t of type "linux-joy",
and then calling ggiJoinInputs with the ggi_visual_t and the new
gii_input_t.
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.
Can anybody help me, please?
I mailed a test program for gii a while back to the list. This is a
little better than the gii test demo and shows two methods:
1. giiQueryDeviceInfo
2. giiQueryDeviceInfobyNumber
and then check the number of axes.
1 has the disadvantage that one already must have received/processed an
event!
A little bit from the program:
if (device_no -1) {
printf("giiQueryDeviceInfo returned: %d\n", giiQueryDeviceInfo(inp,
device_no, devinfo));
printf("%s (%s):\n can generate: %x\n num buttons: %x\n num axes:
%x\n",
devinfo.longname, devinfo.shortname,
devinfo.can_generate,
devinfo.num_buttons, devinfo.num_axes
);
}
Wouter
Re: Keyboard vs Joystick buttons
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". Wouter already answered, how the nicer way works. 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 ... :-). CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: Keyboard vs Joystick buttons
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 ]
