From naaman@.MISSING-HOST-NAME. Fri Jun 4 10:56:44 2004 Date: Thu, 18 Mar 2004 13:44:52 -0800 From: Alexandre Naaman To: Dimi Cc: info-performer@sgi.com Subject: RE: [info-performer] keyboard in performer Hi Dimi, > I had a look at the source of perfly and did not see any key release > code though :( Although I haven't looked through it at length either (for this particular thing) at first glance I don't see any code relating to key-release presses either. > Tha sad thing is that NONE of the Performer Team responded to ANY of my > many questions regarding how to set up KEY-RELEASES or using any other > Windowing system (in the following explanations I'm assuming you're running on Win32; for IRIX & Linux you have to change the names of the tokens and some other details but you'll get the jist of things, I hope!) There are two ways to capture key-releases (key-up) strokes. The first, which requires modifying libpfdu-util can be done by modifying %PFROOT%/Src/lib/libpfutil/input.c. If you look at this piece of code you'll see some tokens for WM_SYSKEYDOWN and WM_KEYDOWN. If you follow the code down to the default part of that switch statement (line 1314) you'll see that this is where we populate the event structure for this keydown event. The equivalent code for WM_SYSKEYUP and WM_KEYUP is effectively a no-op because we only monitor the ALT, CTRL and SHIFT keys. If you want to track the key-up stuff then you should copy the code from the key-down section of code and re-transcribe it there. Then you'll have to consider how to differentiate between a key-up and key-down stroke which we don't do for you. I suggest creating a new token (similar to PFUDEV_KEYBD) but call it PFUDEV_KEYBD_UP or something along those lines. Then in your user code (see detail.c or sk.c in %PFROOT%/Src/pguide/libpf/C/ or /usr/share/Performer/src/pguide/libpf/c/) you can add an extra switch similar to what exists for PFUDEV_KEYBD and you're golden. The other option which doesn't require you to modify any code in libpfdu-util lies within the realm of user callbacks. This can be done by calling pfuInputHandler(). For example you could do: pfuInputHandler(myInputHandler PFUINPUT_CATCH_UNKNOWN); and then declare myInputHandler() as follows (assuming you're running on Win32): void myInputHandler(unsigned int display,unsigned int event, pfuCustomEvent *ev) { pfuWin32Event *event = (pfuWin32Event *)ev; switch(event->uMsg) { case WM_SYSKEYUP: case WM_KEYUP: switch(event->wParam) { /* see code at line 1253 in input.c */ .... which eventually gets you to .... default: { char keyState[256]; char returnBuf[2]; int retVal; if(!GetKeyboardState(keyState)) break; retVal = toAscii(event->wParam, (event->lParam & 0x00ff0000) >> 16, keyState, returnBuf, 0); if(retVal == 0 || retVal == 2) break; // else: YOU HAVE YOU RETURN KEY in returnBuf[0] } break; } break; default: break; } } If you want to do the same thing on IRIX/Linux then you'll have to implement the code above in a similar fashion but parse XEvents instead; I can send you an example of how to do this if you like. > like GLUT or Win32 or Any other toolkit which would enable the user to > decouple the input from performer and let performer just doing what it > can best "RENDERING". We have several libraries, libpf being the core where we handle all of the rendering. If you want to do the input code using a separate library or using your own code then you're free to do so. libpfutil which implements the input code is there for ease of use only and also to help make Performer applications more portable. In the past we used this to help us ship both IRIS GL and OpenGL versions of Performer; nowadays we use it to ship versions of Performer which work with either X style input or Win32 style input. > Furhermore there are NO examples how to set up even a simple WIN32 > application in the Windows version of Performer. Please take a look at %PFROOT%/Src/pguide/libpf. There's a makefile there and all the examples should just build out of the box. There's no need to do anything special to create Performer applications which run on Windows. Look at the makefiles, or just type 'nmake' from %PFROOT%/Src and it will compile tons of examples which work on Windows for you. The few samples which don't work on windows are those which explicitely use Xlib style input and haven't been ported over to use the pfu routines (yet). In addition, there are some aspects of Performer functionality which do not work on Windows and this has been documented in the Programmer/User guides and release notes; the jist of this being that the functionality on Win32 is similar to what exists on Linux except for the lack of MP functionality. > I have to admit that I get more support from the engine guys of many > Freeware Scene Graph when asking in their corresponding mailing like the > OpenSceneGraph, than asking here in the mailing of Performer list which > is supposed to be one of mostly available high performance SceneGraph > engines for licensing. I expected more professional support for > Performer users even if they don have any highly paid SUPPORT CONTRACT. I thought Gordon's answer was sufficient ... also I think this question has been asked before. Hopefully my reply satisfies your needs. Let me know if it doesn't. > > I am using Performer many years now on SGI machines and I am quite > dissapointed about that development. Feel free to send us feedback about what you'd like to see in future releases of Performer; we're always looking for input! A+, Alex. ----------------------------------------------------------------------- List Archives, Info, FAQ: http://www.sgi.com/software/performer/ Open Development Project: http://oss.sgi.com/projects/performer/ Submissions: info-performer@sgi.com Admin. requests: info-performer-request@sgi.com -----------------------------------------------------------------------