3DS
Don Hatch (hatch++at++hell.asd.sgi.com)
Tue, 23 Apr 1996 18:17:01 -0700
On Apr 23, 7:29pm, Allen Bierbaum wrote:
> Subject:
>
> [ plain text
> Encoded with "quoted-printable" ] :
Performers,
> For input processing in my current program, I hacked the input code from /usr/share/Performer/src/pguide/C++/detail.C. I only use the input processing from here. In other words, I use pfuMouse and pfuEventStream to do auto input for a variety of Xformers. I needed the ability to switch between fly, drive, and trackball modes. This was the only program example that I found to do all this.
>
> My program (and detail.C) work fine as long as I compile -32, but if I try -N32 or -64, I have problems. They compile correctly, but when the view comes up, it is as if they receive no input data. I traced the programs through a debugger, and it seems as if the draw loop is doing it's thing fine. The program just doesn't accept any input. I next tried to compile some other program samples included with Performer to see if they allowed input compiled in this way. I compiled the programs in the libpfui directory. They work fine, but they don't use the same method for input. In fact they seem to use a much more difficult and cumbersome way to handle input and xformers.
>
> My question is, have I just run across a known limitation in the event processing code, or is there an error in the detail.C program sample???
>
> I was unable to find any more samples that do input in this way, so I could not check the code for correctness. I really need to be able to compile N32 or 64 because I would like to use STL in some of my current code. It seems that the N32 and 64 bit SGI compilers only support the more advanced features of C++ needed.
>
> Can anyone help me???
This is a bug in libpfutil's input handling that only
manifests in N32 and N64, and will be fixed in Performer 2.1
and future patches.
You can fix it yourself by changing and recompiling libpfutil;
here is the relevant portion of the Performer 2.1 release notes:
| Intermittent loss of input:
| This was a bug in pfu input handling. The return value of XPeekEvent()
| in IRIX 6.2 is random data. The workaround is in Performer 2.1, but
| existing Performer 2.0 and Performer 2.0.1 customers can resolve this
| by changing the IRIS Performer utility library source code for
| input.c to make the main loop as follows:
|
| while (!DeviceInput->exit)
| {
| if (!DeviceInput->inited)
| openXInput(p);
|
| if (DeviceInput->inited)
| {
| /* does not return a value */
| XPeekEvent(theDisplay, &event);
|
| collectXInput();
| }
| }
Don
--
Don Hatch hatch++at++sgi.com (415) 933-5150 Silicon Graphics, Inc.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:52:45 PDT