Matevz Jekovec writes:
> I have PII 333 Mhz with GF2MX 32MB on PCI and 256 MB of SDRAM. I have 
> Abit LX something motherboard and SBAWE64 on ISA (I'm about to buy Live! 
> in the next few days). I would like to run FGFS smoothly (that's about 
> 15-20 FPS) on GNU/Debian Linux unstable and using the latest nVidia 
> Linux drivers.
> By using the latest CVS version I noticed the following things:
> 1) In mode 24 bpp, FlightGear ran faster than in 16 bpp (I also switched 
> the Xfree depth to 24 and 16 then). Is there any known explanation (I 
> haven't made benchmark, but judging by the eye I thought it was faster) 
> for this. I think it's the textures fault as they are in 32 bit palette 
> maybe? (including alpha channel) And FlightGear needs to calculate 
> approximates to 24 output palette then?

It's been my personal experience on a GeForce GO based laptop that
16bpp ran faster and used less texture ram the 24bpp.

> 2) The resolution I had on my X was 1024x768 all the time and I wanted 
> to run FlightGear in 800x600, but had no luck. There was a sign when 
> starting up that it is about to run in 800x600 mode, but when switching 
> to fullscreen, the X mode still stayed 1024x768. I have the possible 
> resolution set in xfree86 config file and ctrl+alt++/- work fine and 
> others applications do change the resolution as well. Is there any 
> parameter to set FlightGear to change the system resolution and runs in 
> that in fullscreen? (I searched for man pages, but haven't found 
> anything) I know it worked in Windows some days.

FlightGear isn't set up to change your display resolution.  It
operates on the presumption that the owner of the machine will set the
desired resolution and it will run on whatever it is given.

> 3) --disable-textures parameter is not working.

This has been depricated.

> 4) Any way to limit the texture size to at most 256*256 or 512*512 
> pixels, because when starting up, the limit of 2048*2048 is set
> AFAIK.

You could remove the Textures.high subdirectory.  My intension is that
the textures in the regular Textures subdirectory should stay within
the 256x256 limit although I've had to go in and fix a few things that
crept through on occasion. :-)

> 5) Around the default KFSO, the framerate is way slower than in e.g. 
> Slovenia. Is there any way to fix that (I know there are way more 
> objects, but still I think it should be faster than 6 FPS when looking 
> to the city or airfield)

The default KSFO airport is pretty complicated with lots of
taxiways... that probably contributes significantly to the difference.

> 6) I tried to disable clouds (and sky blending? Is this the same
> thing because when sky blending is off, there are no clouds) and FPS
> increased from KSFO 5 FPS to about 9, 10 FPS.

disable clouds eliminates the clouds.

disable sky blending *should* draw the sky as one fixed blue color
rather than blending into haze around the horizon, but I haven't
tested that recently.

> 7) By increasing FOV, the framerate decreases drasticly. I would really 
> like to enjoy in a bit wider FOV when playing, but it really hits the 
> FPS. Is this normal?

Yes, especially because you are running on a relatively slower
machine, you will probably find yourself geometry limited.  In other
words the amount of geometry that get's rendered per frame will be the
dominant factor in determining frame rate.  Increasing FOV increases
the amount of geometry (i.e. stuff) that get's drawn per frame.

> 8) By decreasing visibility, the framerate increases drasticly. I like 
> that:)

Yes, this is the same reason as for 7).  By reducing visibility, you
are reducing the amount of scenery the system needs to draw.

> 9) LJLJ airfield (Slovenia) was more or less playable (about 15 FPS 
> average) with turned clouds on.

That's good ... also, there is higher density terrain data for the USA
(well now all of the western hemisphere but we've only used it for the
USA to date) that means that there is often a higher triangle density
in USA areas versus non-USA areas.

> 10) Sunsets look really nice!:)

Thanks Erik for that, I know he put a lot of work into them.

Regards,

Curt.
-- 
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    curt 'at' me.umn.edu             curt 'at' flightgear.org
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to