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]
file target problem
The file target in ggi-devel-000103 invariably segfaults if you ask the file target to write a ppm file rather than a raw file (can send more debugging info if you need it). Works fine in 2.0b2.1. The file target code is the same, so must be somewhere else. LibGGI: Disposing "generic-stubs" LibGGI: Closing handle: 0x80a3688 LibGGI: _ggiZapDL(0x808db50, 0x808edcc) called LibGGI: Disposing "generic-color" LibGGI: Closing handle: 0x80a3a38 LibGGI: _ggiZapDL(0x808db50, 0x808ee34) called LibGGI: Disposing "file" LibGGI: display-file: going down. LibGGI: display-file: GGIresetmode(0x808db50) (segv) Justin
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 ]
Re: XGGI and keyboard input
With my DirectX port of GII, I set sym=label and the appropriate modifiers. You should handle the mapping, i.e. set sym=`function the current modifier+key combination is expected to produce`. I assume Win has provisions to get the keymapping ... does it ? However this is not your current problem. Running XGGI and xterm, I only get lowercase letters. Looking at Xserver\hw\ggi\keyboard.c, which I take to be the keyboard handler for XGGI, I don't see where the modifiers for the keys are handled. How does XGGI know when the modifiers are set? Do I need to send the actual shift, control, alt keys themselves?? Yes. This is necessary anyway for stuff like shift-clicking. Because: Currently I don't send these keystrokes. I use them only to set the modifiers field. That means, that shift-down, click, shift-up is merely invisible ... So the intended method is to send modifier keys as well. Usually with a NIL symbol, as modifiers are not expected to generate symbols. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
BIG bug in GGI (think)
Well, I will report two bugs really. The first one is the most important, you have very good code to handle multi-threading, but you didn't thought in the posibility of one only process reentrant, did you? I've a GTK application that has a ggi_visual inside it (-inwin rules). All seems to work nice, the GGL sprites walk through the screen as they should. First problem, ggi doesnt receive events from this window. I tried to simulate the expose_event with ggiEventSend, but it doesn't seem to work. Well this isn't the bug I'm surely doing something wrong in this. To avoid this, I catch with GTK the expose event and instead of simulate the gii one, I do myself the ggiFlush. But GGL uses alarms to synchronize with the required framerate, and gtk don't know well what uses, but its the same, when I call ggiFlushRegion from gtk it can be drawing a BIG area, which takes a bit, and if in this moment the GGL alarm signal is received, the ggiFlushRegion is interrupted to do ¡other ggiFlushRegion!. You then assume that there is another process accesing the visual and lock the process. But there is only one process reentrant! Is this really a bug or am I doing another thing wrong? If it is, it would help me a lot if you fix it as soon as possible. I can use tricks to avoid this while developing in my house, but I can't distribute the program whith this tricks... And the second bug, is that when I call ggiClose, if the visual is an X-Window, it closes the window ALWAYS, even if the window isn't created by ggi (-inwin). So I can't call ggiClose and I'm losing memory each time I close a gtk window that contains the ggl widget. But this bug doesn't worry me much, the other one is much more dangerous. Thanks -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
