3.2rc1 Overall impression

[KL-666]

@hvengel
I tried that setting after your post. It is called adaptive. Works well too, in that it uses max possible framerates below vert-sync. And above matches vert-sync and stays on 60 fps.

@fmg
If that first picture without 3d clouds is true, which must be true as i can see it, then you are in serious trouble. You did not take that picture at a heavy scenery location like Paris, did you?

Maybe there is a high setting on your computer. I had a lot of trouble with performance until i found a button on my laptop which opened a window with two big buttons: high setting and low setting. It was on low. When i changed it to high, it immediately unleashed all capabilities of the video card too.

Well, hope you find such an option too.

Kind regards, Vincent

[hvengel]

@hvengel
I tried that setting after your post. It is called adaptive. Works well too, in that it uses max possible framerates below vert-sync. And above matches vert-sync and stays on 60 fps.

...

Kind regards, Vincent

I had trouble with the FG frame rate throttling on my machine in that it would throttle to 50FPS no matter what. Turning off the FG throttling and using the drivers adaptive vsync mode was a huge improvement and now I see 60FPS 95% of the time with very high eye candy settings both in the driver settings and FG rendering settings. Using the non-adaptive vsync driver setting I would see much larger frame rate hits when the video card was loaded so the adaptive setting is definitely the way to go. I haven't seen any posts here before about this and now that the usefulness of this setting has been confirmed by someone else I will get on the wiki and add this info.

[onox]

Has any dev tried to disable their nvidia card and use their built-in intel GPU for once? Unfortunately I cannot help test rc1 because downstream wants to wait for the final release.

[Hooray]

Has any dev tried to disable their nvidia card and use their built-in intel GPU for once?

I recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - I do think that a few contributors try to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work. But I do agree that FG would be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:

http://wiki.flightgear.org/FlightGear_Headless
http://wiki.flightgear.org/Testing

Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.

People wanting to change that, need to roll up their sleeves and get involved, and provide feedback.
all testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: http://wiki.flightgear.org/Howto:Optimi ... le_devices

The whole FGCanvas thing (FG with most subsystems disabled) does work even on hardware as old as 7 years: http://wiki.flightgear.org/FGCanvas