From: Alexandre Naaman (naaman++at++laplace.engr.sgi.com)
Date: 01/21/2003 14:00:00
Hi Rob,
> Hi pfAll,
>
> I have just installed Performer 3.0 on a Pentium III 734 MHz with 128MB of
> RAM and a GeForce 2 Ultra video card with XP Pro 2002. Very impressed with
> the ease of installation - Thanks SGI.
Glad you like it :)
(really)
> When running Performer Town, it runs at a max of 2 Hz refresh. Is this
> expected with my set up ?
No ... it should do 60Hz no problem with that kind of config.
> I also had the following messages :
>
> WGL_ARB_pixel_format not present in your OpenGL driver. Performer will
> emulate it.
>
> Using generic graphics type 30.
Ok, so that's no good. What you're going to want to do is specify a visual
for perfly to use. For some reason, with your hw/sw config it's we're not
finding a proper visual.
So here's what you can do ... try running perfly with the -t flag, and
specify a visual id to use. This will bypass the visual selection code and
so you can feed it a visual that you know is hw accelerated (it sure
sounds like you're getting a sw visual.)
Use the wglinfo program (which lives in %PFROOT%/Bin and hence in your
path) to determine which hw visuals you have on your system. Once you've
found one you like then you can set the environment variable
PF_FALLBACK_PIXELFORMAT and we won't go through our visual selection code
and use this value instead. See the Developer Release Notes for more info
about this (you can find a link to them from your start menu.)
Normally the visual you'll want to use will be one of the first listed by
wglinfo. Just make sure it's hw accelerated.
Here's an example of how to run when specifying a visual id:
perfly -t 0x1 town.perfly
> MUSTRUN of stage 1 on CPU 1296 not available for this platform.
Don't worry about that one. We don't support MP on win32.
> No hardware support for VSYNC, frame sync may vary. Assumed 60Hz.
or that one ...
> Unable to load cursor 60, using arrow.
Ok ... in this case what has happened is that although we've included
support for dealing with cursors of all types, we've not bundled into the
library any additional cursors so all we can do is select from the list of
cursors that windows supports by default. What we need to do is convert
all of the X based cursors into Windows cursors and then build libpf such
that they live within there. In the grand scheme of things, it didn't seem
like a huge priority ...
The one weird thing about Windows is that cursors aren't associated to
windows the way they are in X. You can specify what type of cursor to use
when you create a new window class and the SetClassLong() is supposed to
override this but ... it doesn't always work. Anyhoo, we've got some code
to work-around all of this so that if you do load a cursor it will be
constrained to a given pfWindow. It's just that we don't have any
additional cursors currently available at this point in time.
> pfuInitInput(): PFUINPUT_X invalid input mode on win 32. Setting mode to
> PFUINPUT_NOFORK_X.
No need to worry about that one either. Someday (hopefully) we'll figure
out how to handle input from a separate thread and then this warning will
disappear. Unfortunately, my first attempts at getting this to work have
not been very fruitful...
> unable to load cursor 150, using arrow.
Same as above ... if you're really curious check out cursor.c in
libpfutil.
> Do any of these warnings give the reason as to why Performer runs so slow ?
> Even running it without loading any flight file I only get 10Hz.
These warnings are all standard fare on the win32 version of Performer and
should be ingored, for now :)
> Thanks for any help.
So, to sum things up, none of the warnings, except for the generic visual
are of any importance here in determining what is the cause of your
performance problems. Please try out the work-arounds I've suggested above
and let us know how it works ...
Hope this helps ...
A+,
Alex.
This archive was generated by hypermail 2b29 : Tue Jan 21 2003 - 14:00:07 PST