Board index FlightGear Support Graphics

Best Version of FG.

Graphics issues like: bad framerates, weird colors, OpenGL errors etc. Bad graphics ar usually the result of bad graphics cards or drivers.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).
- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Best Version of FG.

Postby Captain LaForest » Wed Jun 17, 2015 5:28 pm

I would like to know which version of FlightGear would provide me with the best performance with FPS. I do not care about how good the airports, and scenery look as I usually have my settings down all of the way anyways. All I am asking for is what version of FlightGear would give me maximum performance on my PC. My PC specs are Intel Celeron N2830 that runs at 2.16 Ghz, 4 GB of RAM (3.89 usable), and Intel HD Graphics. The OS is Windows 8.1.
Captain LaForest
 
Posts: 37
Joined: Tue Jun 02, 2015 5:35 pm
OS: Windows 8.1

Re: Best Version of FG.

Postby legoboyvdlp » Thu Jun 18, 2015 4:33 pm

Try 1.0 for a surprise lol. Maybe 60FPS :P. But seriously, possible any version around 2.6ish, 2.4, 2.2, 2.8. Just download, test, and pick the best one.
But of course, 3.5 is REALLY nice.
User avatar
legoboyvdlp
 
Posts: 7007
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Best Version of FG.

Postby wkitty42 » Fri Jun 19, 2015 3:12 am

of course also realize that using older versions of FGFS may lead to numerous problems if trying to use newer up-to-date craft... not to mention the lack of features that simply do not exist in older versions... let's also not forget that different versions of FGFS may also require different and matching versions of FGDATA...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5644
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Best Version of FG.

Postby fmg » Sun Jun 28, 2015 8:46 am

For me, on Mac, it's the 2.0r284. I can fill up the scenery with objects and have fps around 30 instead 6-7 with the modern FG.
All later versions have some improvements, but in total more drawbacks for me.
Atlas is gone and lot's of things that worked well before for years gets broken and never fixed again or are replaced with something worse. Since 2.10 frame rate also drops significant.
But it get's more and more laborious if you wan't to use actual planes because nearly no one cares about backwards compatibility. Also you can only use the old scenery 1.0.1.
A lot of the new planes can be used in 2.0 if you commend all the Rembrandt-stuff and some effects out. But it's work to do. Some few are so fancy filled up with so many incompatible shortcuts and nasal-code that I gave up.
Guess if like to fly actual versions of modern airlines this could be hard. Also could be, that canvas is also not supported, but I don't know.
I mostly use vintage planes (props & taildraggers), so that's no problem for me.

f-)
User avatar
fmg
 
Posts: 541
Joined: Tue Jun 29, 2010 5:13 pm
Location: EDDI
Callsign: fotomas
Version: 2
OS: Mac OS X 10.6.8

Re: Best Version of FG.

Postby Thorsten » Sun Jun 28, 2015 9:12 am

But it get's more and more laborious if you wan't to use actual planes because nearly no one cares about backwards compatibility.


To be able to use a current aircraft on an old FG version is not backward compatibility but forward compatibility (= you want the binary to support features which will be developed in the future) and that's not technically possible.

Running an older aircraft on the current FG is backward compatibility, and that people usually care about and try to support it where possible.

Since 2.10 frame rate also drops significant.


Actually no - this was the 2.0 scenery introduction point, and using the new scenery drags framerate. If you would run old scenery with the new binary and the same settings, it'd be really fast and efficient.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Best Version of FG.

Postby fmg » Sun Jun 28, 2015 6:09 pm

Thorsten wrote in Sun Jun 28, 2015 9:12 am:
Since 2.10 frame rate also drops significant.

Actually no - this was the 2.0 scenery introduction point, and using the new scenery drags framerate. If you would run old scenery with the new binary and the same settings, it'd be really fast and efficient.

Frame rate went down here from 30 fps in all previous versions to 18 fps with the old scenery in FG 2.10.
Then after installing scenery 2.0 down to 7 fps. So it's not only the scenery.
User avatar
fmg
 
Posts: 541
Joined: Tue Jun 29, 2010 5:13 pm
Location: EDDI
Callsign: fotomas
Version: 2
OS: Mac OS X 10.6.8

Re: Best Version of FG.

Postby Thorsten » Mon Jun 29, 2015 8:19 am

Removing the confunding factors like changes in the defaults or changes in aircraft from version to version, FG is getting faster. There's plenty of optimization that's being done behind the scenes.

Of course pretty much nobody runs 3.5 with the visuals of 1.9, so the comparisons usually made are flawed here. But if you would, it would be faster. A few folks have tested that.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Best Version of FG.

Postby fmg » Mon Jun 29, 2015 9:33 am

I envy this few folks. But this ins't true at least here. Maybe it's only the Mac version. I can't tell. If it would be the other way round I would happily use the new version an avoid all the annoying extra work.
All I've done is to start FG the normal way like all the years before. If it's necessary to make extensive adjustments to get a faster FG then I would be happy you receive a manual for that with the new version.
If my comparison is flawed, I would like to have an advice how to do that properly.
But as you can see here I tried it with eye candy on an all eye candy stuff turned off:
http://forum.flightgear.org/viewtopic.php?f=82&t=23940&sid=6316bb1a1e1f59c61f257a7fcf5209aa&sid=6316bb1a1e1f59c61f257a7fcf5209aa#p218274
Always the same bad results.
Today I would be happy if I can have the frame rate before 2.10 back. Even faster would be a dream.
I don't doubt that there was optimization done. ALS forced no drop in fps here, like it does before. But overall it's getting slower here.

f-|
Last edited by Johan G on Mon Jun 29, 2015 3:05 pm, edited 1 time in total.
Reason: No useless quoting please
User avatar
fmg
 
Posts: 541
Joined: Tue Jun 29, 2010 5:13 pm
Location: EDDI
Callsign: fotomas
Version: 2
OS: Mac OS X 10.6.8

Re: Best Version of FG.

Postby massima » Mon Jun 29, 2015 9:35 am

Thorsten wrote in Mon Jun 29, 2015 8:19 am:......FG is getting faster. There's plenty of optimization that's being done behind the scenes.
.........


True, i can confirm newer versions run better than old version, and i'm using latest scenery, ALS is on (all values are set to zero). I get max 14 fps min 9 fps, my system is very old (amd X2 5600+, ram 2GB, Geforce 8600GT with 1GB).
User avatar
massima
 
Posts: 227
Joined: Sat Jan 03, 2015 6:48 pm
Location: Italy
Callsign: M-AXX
Version: 2019.1.1
OS: debian testing

Re: Best Version of FG.

Postby fmg » Mon Jun 29, 2015 9:55 am

Lucky you!
Last edited by Johan G on Mon Jun 29, 2015 3:06 pm, edited 1 time in total.
Reason: No useless quoting please
User avatar
fmg
 
Posts: 541
Joined: Tue Jun 29, 2010 5:13 pm
Location: EDDI
Callsign: fotomas
Version: 2
OS: Mac OS X 10.6.8

Re: Best Version of FG.

Postby Vladimir Akimov » Mon Sep 21, 2015 10:47 am

Try the 3.2, i use it.
You know me from youtube :)
I'm VladFlyer, take a look :

https://www.youtube.com/channel/UCBOvOg ... yNsYKuAxbw
User avatar
Vladimir Akimov
 
Posts: 630
Joined: Tue Oct 22, 2013 7:05 pm
Callsign: VladFlyer
Version: 3.2.0
OS: Win 8.1

Re: Best Version of FG.

Postby Hooray » Mon Sep 21, 2015 12:17 pm

In general, future FlightGear versions should perform better for you than older ones, however there are also occasional bugs that are introduced along the way, such as leaking resources (memory/listeners).

Depending on your hardware specs, FlightGear may be CPU-bound or GPU-bound, for most people on lower-end (older) hardware it is typically CPU-limited, i.e. quoting postings from the devel list archives not older than ~3 years, made by people involved in the OSG (rendering) department:

http://sourceforge.net/p/flightgear/mai ... /32792620/
Rebecca Palmer wrote:we appear to be single-thread-CPU bound (and if we are on my machine, we probably are on most)


http://sourceforge.net/p/flightgear/mai ... /29563353/
Tim Moore wrote:The depth-pass-only pass is a well known optimization, but the fact it
is not helping implies that our bottleneck is not in fragment
processing. I've suspected for years that it lies on the CPU, and have
been trying to optimize our scene graph a bit...


http://sourceforge.net/p/flightgear/mai ... /29571614/
Mathias Fröhlich wrote:It *is* on the cpu.
At least for most of the use cases. Every now and then there is an other limit
that comes up for specific stuff. But we are *mostly* draw limited. The draws
are way too small to be efficient.
James and I were talking about this some time ago.


http://sourceforge.net/p/flightgear/mai ... /29573519/
Tim Moore wrote:we also have CPU bottlenecks upstream too.


http://sourceforge.net/p/flightgear/mai ... /29727298/
Durk wrote:Tim and Mathias already said that we are CPU bound and I can confirm by experience.


FlightGear core developers are generally aware of this, and are trying to improve performance and compatibility over time. With HLA and fgviewer being the two main efforts to modularize the main loop and turn FlightGear into a set of losely coupled modules that communicate using IPC:

http://wiki.flightgear.org/High-Level_Architecture
http://wiki.flightgear.org/FGViewer

In particular, this will also help troubleshoot performance issues because modules become much better identifiable, i.e. it will be much easier to tell which subsystem is malfunctioning.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Best Version of FG.

Postby Thorsten » Mon Sep 21, 2015 12:19 pm

Is there a particular reason you would not quote any of my test results and statements arguing that we are GPU bound at high rendering quality level?
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: Best Version of FG.

Postby Hooray » Mon Sep 21, 2015 12:29 pm

I wasn't trying to have this discussion again - anyway, we have roughly half a dozen of core developers, involved in the SG/FG and OSG rendering code (C++), able to use system level profilers (oprofile, google perftools), stating quite clearly that FG is typically CPU-limited for the majority of end-users on average/low-end hardware using just the default settings, whereas you ended up posting a bunch of fantastic stats made by someone developing fancy shaders/effects on a $3000 US gaming laptop/workstation with 8 cores, i7 hyper-threading and plenty of RAM IIRC.

Which sums up my reasons for not pulling out your quotes, because it may be another 5-10 decades until such a workstation replacement can be considered to be "average", or even "low-end" hardware.

We have seen now several times how you, and others (myself included), have rejected bug reports from people with average hardware, just because certain issues (actual bugs) would not even show up on our radar, such as tons of RAM being leaked, or property callbacks/listeners being re-registered literally hundreds of times.

So someone stating that he/she cannot even run fgfs with the bare default settings, certainly isn't helped by linking to fancy effects/shader settings that prove that certain end-users, on very particular hardware, may /sometimes/ be GPU-bound, despite having spent $3k US on a gaming workstation.

Subject: Can FG computations be made more balanced?

Hooray wrote:Basically, your GPU is a massively parallel special-purpose cluster of "CPUs" (depending on the hardware, hundreds of tiny cores) that can do certain mathematical computations extremely well/fast by partioning the task at hand and handing each job to another work queue, which may be processed by hundreds of "dedicated cores sitting on the GPU" in parallel. Basically, your GPU is super computer (certainly when compared to the computing power of the 80s or 90s).

On the other hand, not all things can be easily run on a GPU (GPGPU aside for now) - and many parts of FG are simply not rendering-related, and cannot easily be moved to the GPU.

So your CPUs and idle cores are still relevant to handle all non-rendering related jobs, and other computations that are not appropriate for the GPU (ATM). Things like AI traffic, the FDM, autopilot computations, Nasal code - these all run in the main loop, before the final frame is created and rendered. So depending on how long each step takes, frame rate/spacing may fluctuate - which is less likely to show up on really fast systems like Thorsten reported.

Thus, the idea is not to use idle CPU cores for rendering related stuff - but rather optimize the FG<->OSG pipeline such that more main loop resources become available, so that certain tasks can be offloaded onto other cores. For example, OSG is able to run certain rendering-related optimizations asynchronously, outside the main loop. But that requires a paradigm change, because of the way FG makes currently use of OSG in a fairly sub-optimal fashion, even though Thorsten is right in saying that this particular issue doesn't show up on extremely fast systems with high-speed CPUs.

So Thorsten's system is unfortunately not representative of the overall situation for all users - because not everybody has a $ 3k workstation-style laptop at home with 8 64 bit cores (hyperthreading included), 16gb of RAM and a NVIDIA 670M 2gb SLI configuration. We need to be careful not to compare apples and oranges here, I have no doubt that Nasal code or poorly coded C++ code doesn't really show up on such a system.

Which doesn't really mean that anybody in particular would be wrong here, but originally the FG main loop was designed to be a single sequential loop that scaled roughly with the frequency of the CPU - which is why someone running FG on a "high-end" gaming computer today may very well have the impression that FG's architecture is not the problem, especially because of the number of background threads already added over time and now working behind the scenes, which ALREADY make use of additional cores to reduce the footprint of the main loop.

Again, performance issues like these are not obvious on high-end machines, no matter if it's framerate, frame spacing or the Nasal garbage collector - on a 3-4 ghz multicore system, there's usually enough horsepower available to make up for architectural shortcomings - but that only hides the real problem. And it's a well-known issue that computers used by developers are usually high-end machines, which end up masking problems encountered by end users, who may very well use much less powerful hardware.

If we all had access to 10ghz machines, we would all be having the impression that FG's architecture is rock-solid and that GPUs are the main problem :lol:

There's a reason why software companies tend to keep lots of hardware around, to do tests and benchmarks on old/common hardware.

Keep in mind that we still have many people here reporting that Rembrandt wouldn't work too well for them, which really isn't a totally different issue.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Best Version of FG.

Postby Thorsten » Mon Sep 21, 2015 2:35 pm

We have seen now several times how you, and others (myself included), have rejected bug reports from people with average hardware, just because certain issues (actual bugs) would not even show up on our radar, such as tons of RAM being leaked, or property callbacks/listeners being re-registered literally hundreds of times.


Actually there was once instance of a bug report where I asked for further test data rather than taking the conclusion of the OP on face value - who turned out to have been right.

And, well, we also have a report with an 8600 GT with ALS on, which is likely GPU limited as even at minimal settings ALS would drag a lot at an old card. Not a report with minimal graphical settings.

But what do I know... oh wait, I actually own a computer with an 8600M card! I know first-hand how ALS slows it down...
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Next

Return to Graphics

Who is online

Users browsing this forum: No registered users and 3 guests