Boy, it sure looks like I really kicked over an ant-hill with
this question, 'eh?
Hooray wrote in Fri Jul 10, 2020 4:46 pm:Speaking in general, it would make sense for people with similar hardware (Pi, Nano etc) to team up and define a safe subset of features to make legacy code optional, so that it can be excluded during compilation - that would possibly include stuff like the 2D panels code, the legacy HUD and the PUI UI.
In fact, the most proper way to tackle a "port", would actually be a headless build, i.e. with all the graphics stuff excluded for starters:
http://wiki.flightgear.org/FlightGear_HeadlessHaving a team of contributors who are interested in retargeting FlightGear onto embedded hardware could be pretty cool for the project, too - because many performance issues that may only show up after hours of running fgfs, will show up much earlier (or much more prominently) on such constrained hardware.
Perhaps there could be a specific sub-forum for the embedded hardware crowd?
Hooray talked about a dedicated Wiki section - all good - but I think a separate forum space will attract more attention more rapidly as people tend to look in the support fora first. (At least that's what I do.)
One thought I had when I was thinking about running FG on the 'Nano was the advanced, and dedicated, graphics hardware on the 'Nano.
Unlike a "normal" system, I thought that running FG on the 'Nano would provide access to the advanced hardware without all the competition found in a larger system. In essence an "embedded" FG install, on a system that (might) be able to pull it off.
Not that I am advocating a "FG game system", but it seemed to me that a system built for and only running FG, would be able to do many wonderful things without a huge hardware expense on super-advanced graphics, processors, and memory.
Here's a thought that is the conjunction of "headless" and "embedded":
Maybe later on when the dust has settled, (and perhaps after a total refactor of the FG code has been done), various parts of the FG functionality could be loaded and run on a number of networked modules - AKA a FlightGear Cluster.
I can easily see someone creating functional hardware modules that each provide some small, and easily configured, part of the entirety of the FG experience. Want more 4k-HD monitors? Add a few more 'Nanos, each one exclusively responsible for it's own share of the whole display task. Meanwhile the small module that is responsible for Just-In-Time terrain loading doesn't have to worry about who's going to render what part of what section.
This could get
REALLY interesting and
REALLY hairy,
REALLY quickly!
====================
One thing needs clarifying:
When you're looking at the embedded hardware crowd, "embedded", (even if using the same basic processor family), is not even close to "similar".
Even clones of the
exact same hardware can be vastly different depending on who did the cloning. (
i.e. "Original" Arduino, SparkFun, Seeed Studios, Vellman, etc.)
Virtually every embedded system out there is based on
a very specific, (and
highly customized), system-on-a-chip that was designed and manufactured to present a very specific use-case to the world.
In the case of the Pi, it was/is designed to be a very inexpensive, (< $50 USD), makerspace computer that would run a "real" O/S, instead of being low-level programmed like the Arduino.
The 'Nano is intended for those who are exploring robotics and AI, who have outgrown their 'Pi based systems and 'bots, who want advanced "CUDA-core like" programmable rendering pipelines that can be used for more advanced processing, and still have a 'Pi-compatible GPIO header and a relatively small physical footprint.
That these disparate systems can be used for something like FG is a tribute to the ingenious people who absolutely insist on getting that dad-gummed square peg into that pesky round hole.
All good, but be careful. These systems are not nearly as "similar" as you may think.
Maybe this is what should be etched into the bottom of the mirror:
Warning! Differences are larger than they appear!