From: Alexandre Naaman (naaman++at++laplace.engr.sgi.com)
Date: 03/18/2004 13:44:52
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.
This archive was generated by hypermail 2b29 : Thu Mar 18 2004 - 13:46:36 PST