Board index FlightGear Support Compiling

Download_and_compile.sh & Raspberry Pi4  Topic is solved

Building FlightGear from source, and in the need for help?

Re: Download_and_compile.sh & Raspberry Pi4

Postby V12 » Fri Apr 03, 2020 11:16 am

On LUbuntu 19.04, 18.04 or 20.04 night build and FG 2019.1.2 with active DDS cache the cloud LOD is broken.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Download_and_compile.sh & Raspberry Pi4

Postby enrogue » Fri Apr 03, 2020 12:18 pm

Well I guess you get to choose - mildy broken LOD on clouds with DDS or stuffed up transparencies giving you a lovely black square for a Sun etc

The truth is we can't fix the texture format issue on the Pi as it's a driver/hardware issue, and the reality is you aren't going to be able to run a Pi4 with huge visbility as it can barely handle default visbility with the default renderer at 1280x800
User avatar
enrogue
 
Posts: 292
Joined: Mon May 19, 2014 7:40 pm
Location: London (UK)
Callsign: enrogue
OS: Ubuntu, macOS

Re: Download_and_compile.sh & Raspberry Pi4

Postby V12 » Fri Apr 03, 2020 1:38 pm

I choose platform, where the sim will be enjoyable, not only runable.
But You are right, better clouds with short visibility than black rectangles and texture problems with clouds visible from 60 kilometers.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Download_and_compile.sh & Raspberry Pi4

Postby Hooray » Fri Apr 03, 2020 1:43 pm

being able to run fgfs on such, comparatively low-powered, system is actually a good thing for fgfs as a whole - it can help us understand bottlenecks that are hardly visible on typical gaming rigs, but that may still show up over time (think leaking listeners/memory) - this sort of thing can also be considered the prerequisite for people wanting to target/build/run fgfs on other embedded hardware, such as thin clients with integrated GPUs or even mobile phones (think Android)

In other words, if the right people were to team up to specifically such hardware, this could also mean significant performance improvements for people on powerful gaming rigs.
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: Download_and_compile.sh & Raspberry Pi4

Postby enrogue » Sat Apr 04, 2020 5:11 pm

I'm very interested in seeing how FlightGear runs on low end hardware - I have a collection of it :)

Probably to do it initially, gles1 would have to be used - I think gles2 has no fixed function - and simgear/flightgear would have to be patched to use only OSG calls (if possible)

I know OSG can have gles{1,2} support without windowing compiled in

I have some more screenshots here:

Image

Image

Image

Image
User avatar
enrogue
 
Posts: 292
Joined: Mon May 19, 2014 7:40 pm
Location: London (UK)
Callsign: enrogue
OS: Ubuntu, macOS

Re: Download_and_compile.sh & Raspberry Pi4

Postby Hooray » Sat Apr 04, 2020 5:40 pm

It would be pretty easy to disable/exclude legacy OpenGL code via #ifdef macros and/or if(fgGetBool()) {} blocks to keep things disabled that are not supported.
That would work in the short term, we have previously used this approach to disable complete subsystems: http://wiki.flightgear.org/Howto:Disable_Nasal_entirely

It is straightforward to add the corresponding #ifdef blocks where they're needed, and then edit CMakeLists.txt to add a corresponding build target to disable legacy OpenGL code: http://wiki.flightgear.org/Developing_using_CMake

But sooner or later it might also make sense to implement support for "startup profiles" that keep certain subsystems entirely disabled:

http://wiki.flightgear.org/Startup_Modes
http://wiki.flightgear.org/Startup_Profiles

This kind of work could also boost related efforts targeting other non-PC hardware, e.g.:

http://wiki.flightgear.org/Howto:Optimi ... le_devices
http://wiki.flightgear.org/FlightGear_and_old_Hardware
http://wiki.flightgear.org/FlightGear_on_Android

Erik has previously implemented support for graphics card profiles, and his approach would also work to use XML overlays to disable feature that isn't necessary/supported on embedded/RPi-style hardware: http://wiki.flightgear.org/Graphics_card_profiles

This kind of functionality could then also be very handy for regression testing purposes, and for benchmarking: http://wiki.flightgear.org/FlightGear_Benchmark

However, the first step really is adding a new cmake target to disable legacy GL code, and then incrementally add the corresponding #ifdef blocks to FlightGear - i.e. to remove stuff like the splash screen, 2D panels, HUD and PUI

That can be accomplished with very few changes, and then you'd end up with a build mode to build FlightGear without those features.

Once that is working, the next step is turning #ifdef blocks into startup/runtime options (i.e. the fgGetBool() stuff I mentioned 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: Download_and_compile.sh & Raspberry Pi4

Postby enrogue » Sat Apr 04, 2020 10:31 pm

Ah - the graphics profile thing, that reminds me:

This is the profile used in the screenshots:

Code: Select all
?xml version="1.0"?>

<PropertyList>
  <shaders>
    <custom-settings type="bool">true</custom-settings>
    <clouds type="double">0</clouds>
    <generic type="double">1</generic>
    <landmass type="double">3</landmass>
    <model type="double">0</model>
    <contrails type="double">1</contrails>
    <crop type="double">0</crop>
    <skydome type="bool">false</skydome>
    <transition type="double">0</transition>
    <urban type="double">0</urban>
    <water type="double">3</water>
    <wind-effects type="double">0</wind-effects>
    <vegetation-effects type="double">0</vegetation-effects>
    <forest type="double">0</forest>
    <lights type="double">3</lights>
    <quality-level-internal type="double">3</quality-level-internal>
    <quality-level type="double">-1</quality-level>
  </shaders>
  <random-objects type="bool">true</random-objects>
  <random-vegetation type="bool">true</random-vegetation>
  <random-vegetation-shadows type="bool">false</random-vegetation-shadows>
  <random-vegetation-normals type="bool">false</random-vegetation-normals>
  <vegetation-density type="double">1</vegetation-density>
  <random-buildings type="bool">false</random-buildings>
  <building-density type="double">1</building-density>
  <point-sprites type="bool">true</point-sprites>
  <particles type="bool">true</particles>
  <clouds3d-enable type="bool">true</clouds3d-enable>
  <clouds3d-vis-range type="double">10000</clouds3d-vis-range>
  <clouds3d-detail-range type="double">10000</clouds3d-detail-range>
  <clouds3d-density type="double">0.25</clouds3d-density>
  <shadows>
    <enabled type="bool">true</enabled>
  </shadows>
</PropertyList>


It's saved here: (called 'V3D 4.2.xml')

https://www.dropbox.com/s/dfp8b4y1q41jp ... 2.xml?dl=0
User avatar
enrogue
 
Posts: 292
Joined: Mon May 19, 2014 7:40 pm
Location: London (UK)
Callsign: enrogue
OS: Ubuntu, macOS

Re: Download_and_compile.sh & Raspberry Pi4

Postby Hooray » Sun Apr 05, 2020 9:19 am

it might be a good idea to ask someone with commit access (Erik?) to get this committed to $FG_ROOT, so that people on RPi-style hardware can simply use the profile, as per Erik's original idea:

Review of FG on reddit: xpost
erik wrote:This is way over thinking of what I had in mind.
The only thing I want to do is detect the video card and based on the GL renderer name turn on ALS (or not), turn on water shader (or not), turn on the 3d city shader (or not), etc.

The default would not be touched but based on the detected video card certain options would get enabled, making the first impression much more pleasant (for first time users).

Erik


Alternatively, we could branch sg,fg and fgdata and commit all related changes there to file a merge request - which would then include build time options to use GLES, and disable stuff like PUI, HUD, 2D panels - basically, to end up with a bare bones fgfs executable that can be built/executed using OpenGL ES only

The corresponding changes are rather straightforward, it's not so much about coding, but about disabling existing code/features - i.e. by adding a new CMAKE build option and using the corresponding #ifdef blocks to fg_init.cxx and other places referencing the corresponding subsystem.

For instance, optional features are added to CMakeLists like this: https://sourceforge.net/p/flightgear/fl ... s.txt#l189
Code: Select all
# additional utilities
option(ENABLE_FGELEV     "Set to ON to build the fgelev application (default)" ON)
option(WITH_FGPANEL      "Set to ON to build the fgpanel application (default)" ON)
option(ENABLE_FGVIEWER   "Set to ON to build the fgviewer application (default)" ON)
option(ENABLE_GPSSMOOTH  "Set to ON to build the GPSsmooth application (default)" ON)
option(ENABLE_TERRASYNC  "Set to ON to build the terrasync application (default)" ON)
option(ENABLE_FGJS       "Set to ON to build the fgjs application (default)" ON)
option(ENABLE_JS_DEMO    "Set to ON to build the js_demo application (default)" ON)
option(ENABLE_METAR      "Set to ON to build the metar application (default)" ON)
option(ENABLE_STGMERGE   "Set to ON to build the stgmerge application (default)" OFF)
option(ENABLE_FGCOM      "Set to ON to build the FGCom application (default)" ON)
option(ENABLE_QT         "Set to ON to build the internal Qt launcher" ON)
option(ENABLE_TRAFFIC    "Set to ON to build the external traffic generator modules" ON)
option(ENABLE_FGQCANVAS  "Set to ON to build the Qt-based remote canvas application" OFF)
option(ENABLE_DEMCONVERT "Set to ON to build the dem conversion tool (default)" ON)
option(ENABLE_HID_INPUT  "Set to ON to build HID-based input code" ${EVENT_INPUT_DEFAULT})
option(ENABLE_PLIB_JOYSTICK  "Set to ON to enable legacy joystick code (default)" ON)
option(ENABLE_COMPOSITOR "Set to ON to enable the Compositor-based Viewer" OFF)
option(ENABLE_SWIFT      "Set to ON to build the swift module" ON)


in fg_init.cxx the corresponding #ifdef block looks like this: https://sourceforge.net/p/flightgear/fl ... .cxx#l1043
Code: Select all
#ifdef ENABLE_AUDIO_SUPPORT
    ////////////////////////////////////////////////////////////////////
    // Initialize the sound-effects subsystem.
    ////////////////////////////////////////////////////////////////////
    globals->add_subsystem("voice", new FGVoiceMgr, SGSubsystemMgr::DISPLAY);
#endif


Other obvious candidates to be disabled would be:
the HUD: https://sourceforge.net/p/flightgear/fl ... t.cxx#l939
the PUI/XML GUI: https://sourceforge.net/p/flightgear/fl ... t.cxx#l961

Also, most of the stuff in $FG_SRC/Cockpit would be incompatible: https://sourceforge.net/p/flightgear/fl ... c/Cockpit/

So, a good starting point would be to add build options like:

  • DISABLE_HUD
  • DISABLE_PUI
  • DISABLE_2DPANELS

The next step would then be to add an ENABLE_GLES mode that automatically disables HUD/PUI/2D panels

This build mode would then only build a subset of FlightGear, so that it will be much easier to target RPi-style hardware (or other GLES targets like Android phones/tablets)

A good starting point would be creating a wiki page with a table of affected folders, e.g. by grepping $FG_SRC for "glBegin" and "glEnable" statements, to build a table of sources that would need to be excluded/ported. We could probably even use a script to update CMakeLists.txt accordingly.

Even though I believe fg_init.cxx and any runtime places referencing such code would need to be manually patched using the corresponding #ifdef macros

EDIT: Okay, there's now a first stab at a wiki article aimed at people interested in identifying/removing subsystems containing legacy OpenGL code that isn't compatible with OpenGL ES: http://wiki.flightgear.org/FlightGear_and_OpenGL_ES

This is obviously work in progress, i.e. not finished. I used "PUI" (our legacy OpenGL based GUI engine) as an example, because it's a long-standing feature request to get rid of PUI. The process is not specific to PUI however, i.e. should work just as well for similar subsystems like the HUD/2D panels stuff. Basically the thinking was, if we manage to remove PUI, removing other subsystems is pretty straightforward in comparison. Again, contributions/wiki updates/feedback and patches would obviously be appreciated.
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: Download_and_compile.sh & Raspberry Pi4

Postby Puffergas » Mon Apr 06, 2020 12:57 am

enrogue, those are some impressive screenshots.

@Hooray , I uploaded some screenshots to the wiki. Some below:

[[File:Pi4 ADW-ERI 1.png|thumb|Raspberry Pi4]]
http://wiki.flightgear.org/File:Pi4_ADW-ERI_1.png

[[File:Pi4 ADW-ERI 2.png|thumb|Raspberry Pi4]]
http://wiki.flightgear.org/File:Pi4_ADW-ERI_2.png

[[File:Pi4 ADW-ERI 4.png|thumb|Raspberry Pi4]]
http://wiki.flightgear.org/File:Pi4_ADW-ERI_4.png

[[File:Pi4 ADW-ERI 5.png|thumb|Raspberry Pi4]]
http://wiki.flightgear.org/File:Pi4_ADW-ERI_5.png

[[File:Pi4 ADW-ERI 7.png|thumb|Raspberry Pi4]]
http://wiki.flightgear.org/File:Pi4_ADW-ERI_7.png

[[File:Pi4 ADW-ERI 13.png|thumb|Raspberry Pi4]]
http://wiki.flightgear.org/File:Pi4_ADW-ERI_13.png

[[File:Pi4 ADW-ERI 15.png|thumb|Raspberry Pi4]]
http://wiki.flightgear.org/File:Pi4_ADW-ERI_15.png

[[File:Pi4 ADW-ERI 16.png|thumb|Raspberry Pi4]]
http://wiki.flightgear.org/File:Pi4_ADW-ERI_16.png

[[File:Pi4 Desk.jpg|thumb|Raspberry Pi4 running flightGear. One touchscreen and Raspberry P3 A+ with Phi PFD and a second with Phi radio stack.]]
http://wiki.flightgear.org/File:Pi4_Desk.jpg
Puffergas
 
Posts: 56
Joined: Thu Jan 02, 2020 2:09 am

Re: Download_and_compile.sh & Raspberry Pi4

Postby Puffergas » Tue Apr 28, 2020 3:36 am

enrogue wrote in Tue Feb 18, 2020 1:15 am:I'll just post this here now, I have a successful compile on Debian 10 armhf (via an LXD container on a RK3399 powered Rock960 which runs ubuntu 64bit), and on an RPi3B

The method:



I missed the most important post !! :oops:

I'll have too give it a try and add it to the Wiki.
Puffergas
 
Posts: 56
Joined: Thu Jan 02, 2020 2:09 am

Re: Download_and_compile.sh & Raspberry Pi4

Postby Hooray » Sun May 24, 2020 4:14 pm

Note that on RPi-style hardware (or Intel GMA), you'll likely want to disable the PUI GUI and/or at least enable auto-hiding of the menu bar, since that may have a massive impact, i.e. I've seen 25 fps going to 45+ fps without the PUI GUI visible. Note that this is just the effect of disabling the rendering of the menu bar - in other words, totally disabling/removing the whole subsystem has an even greater effect

I once tested this using a script for benchmarking purposes, and it would reliably be 45ms/30fps vs. 25ms/55 fps (without any PUI shown)

Thus, I would definitely suggest to add this to the graphics profile for people on similar hardware, and then share that with other RPi users, it can make a huge difference.

(Note that there is an alternate/external UI called Phi, but using and auto-hiding PUI will do for starters)
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: Download_and_compile.sh & Raspberry Pi4

Postby Puffergas » Sun May 24, 2020 5:40 pm

Maybe this is in /home/pi/.fgfs/autosave_2020_2.xml ?

Code: Select all
    <menubar>
      <visibility type="bool">false</visibility>
      <autovisibility>
        <enabled type="bool">false</enabled>
      </autovisibility>
    </menubar>
    <gui>
      <current-style type="int">1</current-style>
      <devel-widgets type="bool">false</devel-widgets>
    </gui>


Never have noticed any improvement with hiding the menu bar with [SHIFT] + [F10], maybe I need too be more observant. I have never tried the auto hide option.
Puffergas
 
Posts: 56
Joined: Thu Jan 02, 2020 2:09 am

Re: Download_and_compile.sh & Raspberry Pi4

Postby Hooray » Sun May 24, 2020 5:53 pm

To check for yourself if this has any impact with your hardware or not, simply enable fps/ms display and then show/hide the menubar while observing both metrics for a couple of seconds (5-10)
If that isn't conclusive yet, open one of the PUI dialogs and see if/how performance degrades (or not)
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: Download_and_compile.sh & Raspberry Pi4

Postby Puffergas » Sun May 24, 2020 10:11 pm

With full screen, setting on the apron with the aircraft not running, there is almost no change. A few dialog windows will drop one frame from 25 fps to 24 fps. Most windows do not seem to affect performance. The menu bar showing doesn't seem too have any affect. Same thing with two monitors and stuff on the second monitor, however that is not germane to this subject. I have been displaying the fps for about two months and have not noticed the menu bar affect performance, however I have not consciously been making a note of it. I will from now on. Maybe it needs too be a compiled option to have an affect.
Puffergas
 
Posts: 56
Joined: Thu Jan 02, 2020 2:09 am

Re: Download_and_compile.sh & Raspberry Pi4

Postby Puffergas » Mon May 25, 2020 12:55 am

I do notice a performance hit when FG is running in a window. It is a little complicated because FG starts out at ~35fps but after a bit of time drops to ~30. This is all with no menu bar.

Turn the menu bar on, for the first time, and it drops a couple fps. Open a dialog box and it drops to 22fps or less. After that, with menu off, it only hits 28fps at most. Yes, FG running in a window and the menu bar and dialog boxes drop performance.

Seems steady when running in a full screen. Maybe that is why I like to run full screen and adjust the screen resolution. That was an old method from about 25 years ago.
Puffergas
 
Posts: 56
Joined: Thu Jan 02, 2020 2:09 am

PreviousNext

Return to Compiling

Who is online

Users browsing this forum: No registered users and 5 guests