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.

Re: Best Version of FG.

Postby Hooray » Mon Sep 21, 2015 3:59 pm

sorry, I didn't even realize that this is an old thread - so I just looked at the introductory posting (from June) and was referring to those specs/settings (no ALS mentioned there at all), I didn't look at the subsequent postings (which also happen to be old).
Still, the truth is that people who are GPU-limited can usually do something about it, while being CPU-limited is a completely different issue, and very unlikely to show up for power users (like the two of us).

Honestly, you cannot really understand the importance of the difference unless you are able to patch FG and build from source, using tools like a CPU/GPU profiler and debugger to differentiate between CPU/GPU level issues and vice versa.

There are major issues like the mark/sweep Nasal GC or redundant/leaking listeners, memory management issues (or the effects cache) that don't show up for people on powerful hardware with plenty of horsepower, like Torsten, ThorstenB, you and I have repeatedly confirmed.

This was never about you owning a 8600M-based laptop or not, if anything, it is about enabling people to draw the proper conclusions by using all the tools at their disposal, including CPU/GPU profilers - like Mathias, Tim, Fred and others did.

Otherwise, we will keep on seeing end-users with lower-end hardware who report bugs that we cannot even see, let alone reproduce, due to the sheer horsepower of our hardware, or simply our unwillingness to fire up a profiler to see what the CPU and GPU are actually doing.

And doing that would be useful even regardless of ALS or other effects/shader based features, because the majority of end-users are likely to be CPU-limited anyway (as per the core developer comments quoted above)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Best Version of FG.

Postby Thorsten » Tue Sep 22, 2015 10:42 am

Yes, so then the end user has a tape. To get the information I want, he then needs to place it somewhere where I can download it, and I need to view it. Rather than just asking for three numbers in the forum.

I want the relevant information quick and ready - I don't have time to download and review tapes for every bug report as a default.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Best Version of FG.

Postby Hooray » Tue Sep 22, 2015 11:00 am

sorry, but somehow you still misunderstand:

  • you come up with 2 scenarios for telling if a setup is cpu or gpu-limited
  • we record 2 fgtapes for each scenario and add those to $FG_ROOT (to be shipped with each future release)
  • those fgtapes would serve as benchmarks, using your heuristics for telling if something is cpu/gpu-limited
  • next, we add a snippet of Nasal code to menubar.xml to load/run each fgtape, and watch frame spacing/rate
  • with that data, we can either populate a property or dump everything to the console or a text file

Thus, you would end up with a built-in mechanism for running your heuristics, while enabling end-users to provide the data that you need for troubleshooting bug reports. So end-users would not need to record/share any fgtapes, the only purpose of the two ftapes would be to run simple benchmarks (aircraft, location, view direction etc) - all of these properties are automatically sampled by the system.

The only thing missing is a separate XML file for also overriding any rendering related settings/properties, i.e. to ensure that effects/shaders are disabled/enabled for the benchmark to be conclusive.

So, the working procedure for us would be to ask people to go to the DEBUG menu, and run something like "Benchmark", which would then load the two fgtapes we put into $FG_ROOT, and log the frame rate/spacing properties to the console (or a log file), which could then be posted on the forum.

We would never ask people to post/share their fgtapes for review, but use fgtapes stored in $FG_ROOT as a well-defined test-case (e.g. your heuristics above)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Previous

Return to Graphics

Who is online

Users browsing this forum: No registered users and 4 guests