On Thu, 18 Sep 2008 04:28:16 -0700 (PDT), Saurabh wrote in message
> Hi David,
> When I read your email, it intuitively felt like that was it. Your
> description matches so well with the behavior that I am seeing,
> (except for the warning messages on the console). Felt like your
> suggestion was on the money. Very eagerly I tried it but alas that
> didnt help either. I feel mighty discouraged.
..on my via box (AthlonXP1600+, 2G ram, OpenChrome driver (with
X smear bug) "@4xAGP"), "disable_lowimpact_fallback=true fgfs \
--geometry=1920x1440 --httpd=5555 --jpg-httpd=5556 \
--prop:/controls/gear/brake-parking=1 &" says 3fps,
according to my http://192.168.1.86:5555/sim/frame-rate now at
KSFO daybreak, up 1 from 2. ;o) Still researching the smear bug.
Setting up auto-refresh on your browser off the jpg-server, you
can actually fly the damned thing. ;o)
> On a separate note
> I use the puppy linux live cd for flightgear 1.0 on another machine
..have you tried that puppy FG cd on this machine?
> to play flightgear at work sometimes, on a server procured a little
> in advance and will be commissioned for its intended place in the
> server room soon but till then I am having a little fun with it.
> Anyway puppy linux works very well for this case and gives me
> heartfelt joy playing the game. Good machine too dual quad core 8gb
> memory pci-e nvidia framebuffer 512mb video ram, and I dont have to
> disturb what is installed there already. So today I tried using the
> Saitek Aviator AV8R joystick with it but it did not work out of the
> box. Disappointed I did some poking around and found the solution.
> The kernel recognized it off the bat. dmesg had it but js_demo was
> picking NADA.
> The solution is to do modprobe joydev;
> Halaluja developers have done a good job mapping the axis and buttons
> on it.
> btw any more suggestions for that radeon?
..try all puppy, drivers etc updates on that live Puppy for FlightGear
live CD, put your session on an usb key or on disk so you don't have to
waste time on your next sessions, it might teach us a few useful things.
> --- On Wed, 9/17/08, David Slocombe <slocombe@...> wrote:
> > From: David Slocombe <slocombe@...>
> > Subject: Re: [Flightgear-devel] is linux ppc version non-functional?
> > To: flightgear-devel@...
> > Date: Wednesday, September 17, 2008, 11:08 AM
> > Saurabh:
> > As you have "direct rendering: Yes"
> > and you are using a radeon, but you are getting < 1 fps
> > (and some other GL apps work fine)...
> > If you are getting some warning message about fallback to
> > software rendering in the xterm that you started fgfs in,
> > which you will see when you exit the program:
> > Then try this:
> > $ disable_lowimpact_fallback=true fgfs
> > If this fixes the problem, then you can do one of:
> > - put the above in a shell-script and invoke that
> > - put that env var in your .bashrc (and export it)
> > - put the equivalent into a .drirc file in $HOME:
> > "<option
> > name="disable_lowimpact_fallback"
> > value="true" />"
> > (search for .drirc for rest of file's
> > syntax)
> > - update your GL-related RPMs to rawhide
> > ("fc10").
> > (NOTE: all this is predicated on your using fgfs 1.0.0
> > (plib version).
> > I haven't tested it with OSG: it is *possible* that OSG
> > version doesn't
> > invoke the offending GL features. But if you get the
> > warning msg(s) mentioned
> > above even with OSG version, then this stuff does apply.)
> > I had this problem, with an Athlon 1800XP and a Radeon 9550
> > (r300 architecture)
> > and was getting 20-seconds-per-frame (0.05 fps). It jumped
> > to 20 fps with the
> > above fix. (These measured by the first few frames after
> > the splash-screen
> > goes away, using --aircraft=c172p and --airport=khaf.
> > Various Xorg.conf options
> > had no effect, just as you found. My OS was either
> > f8-fully-updated or early f9,
> > as this was last spring.)
> > (You can calculate your "true" (slow) fps by
> > watching the instruments settle after
> > the splash-screen goes away! ;-))
> > The back-story:
> > About 3 years ago, in the r300 support (I forget just which
> > file), s/w
> > rendering was enabled by default if certain h/w features
> > were missing from
> > the graphics chip. It was never documented or publicized.
> > This does
> > not affect many 3D applications but does affect fgfs. No
> > one on this
> > list twigged to this apparently (at least according to my
> > searches of the ML).
> > Fortunately I found it reported and explained on a
> > mailing-list devoted to Google Earth, which was also
> > affected.
> > Some months ago, Dave Airlie reversed the default in the X
> > r300 support
> > so now the s/w fallbacks happen only if that env var is set
> > to false.
> > He applied this change to the next rawhide update for
> > fedora (i.e. fc10),
> > and I found that the rawhide GL RPMs all work fine on top
> > of my fully-updated
> > Fedora 9, so I don't need this kludge anymore.
> > Here's hoping this helps.
> > david.
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.