FlightGear and old hardware
| Working together |
|---|
| The project as a whole: |
| Users and feature requests: |
| Communication: |
| Portability & Compatibility |
|---|
| Performance |
| Efforts |
While FlightGear keeps improving, more and more people - not just users - are starting to consider if anyone is thinking about users with old and/or low-end PCs that can't use the latest features. This concern keeps coming up on the forum and the devel list, and discussing this problem is starting to take up considerable resources, even to just moderate those threads, that tend to turn into very heated debates.
|
FlightGear is a piece of cross-platform software, and the more platforms/use-cases it supports, the better its code base will become over time.
Therefore, it is generally not a good idea to tell others to switch away from Intel or ATI/AMD hardware to Nvidia graphics cards for the same reasons - seriously: all of you are getting to shape the way FlightGear will work 5+ years from now to varying degrees (depending on your own involvement) - no matter if that means OS/platform support, 32 bit support, CPU/RAM requirements or VRAM/GPUs/graphics cards. |
|
|
|
Admittedly, FlightGear isn't quite there yet - but things like the "minimal startup profile" already demonstrate that it is feasible to provide a "safe mode" when booting FlightGear, and incrementally raise system requirements along the line - not unlike your OS "booting" (POST, BIOS, real mode, protected mode etc).
|
|
A selection of responses have now been copied here to present the general consensus among contributors, so that we can hopefully avoid having the same debates over and over, and simply post a link to this wiki article. We are hoping to extend this article over time - analogous to the How the FlightGear project works article which has proven to be quite a success.
Developers have powerful hardware
Admittedly, it is a known problem in software development that developers tend to have fairly powerful hardware (especially game/3D developers!). As developers/contributors we do not have access to each and every conceivable hardware configuration - usually, we also just happen to have a single computer, so that is what we're testing on. And quite a few of us have either purchased systems specifically for FlightGear, or machines that are intended to be used for software development - i.e. are fairly powerful by design. It happens so that algorithmic performance often suffers because things are "fast enough" for those developers.
What does supporting old computers imply?
Making things better configurable and even optional isn't exactly "rocket science", but it's also not very popular, because it is not as gratifying as coming up with a bunch of new features that look stunning. Improving this, entails quite a bit of refactoring work that can only really be measured in terms of performance improvements, while visuals will not change drastically.
Technically, most of us developers would also appreciate just having fixed hardware recommendations that are adjusted over time as necessary, i.e. for each major release cycle (once per year) - but from a usability point of view, we would regret not being able to run FG on certain hardware, including very old hardware.
The need for feedback
The situation can only be improved if people help us and provide feedback.
We'd suggest to "team up" with people who have similar hardware, restrictions and goals, and then actually test FlightGear and regularly provide feedback to the developer community. You could even create a wiki article or forum thread to report what's working and what isn't, and what is performing too slowly.
Otherwise, there's simply no way for developers/contributors to really know where things are "broken" for people with old hardware unfortunately. Of course that requires involvement, but if you truly care, you'll want to get involved to improve things.
Plans for improving performance testing
"Feature scaling" is a long-standing feature request, and it simply involves making features better configurable, which also happens to be a key ingredient for runtime benchmarking, i.e. "in-game" profiling, which is another thing we're interested in supporting sooner or later.
Not so much to have 1:1 performance benchmarks, but rather to do regression testing in an automated fashion in some kind of FlightGear Headless mode, so that certain problems can no longer go unnoticed, without us having to do lots of manual testing.
To sum it up, we are certainly on the right track here, but once this is done, it will only mean that testing will be easier, but still has to be done by the end-users.
We need user collaboration
However, the main issue here really is manpower and involvement: we need many more people like you to help ensure that FlightGear is not crippled for users who may not have access to the latest hardware (for whatever reason).
That said, this involves more than just coming to the forum/devel list and making critical posts - you need to be proactive, i.e. actually test new stuff and report back here, preferably using the devel list or the issue tracker, to ensure that developers are made aware that certain features need to become more optional, better configurable.
Posts from the forum
Baseline Requirements
Well, yes, we could point out that you need a computer, electricity, an operating system installed, harddisk space,... we just operate based on the assumption that people know that computers come with different performance, that software has different requirements and that one needs to adjust options to match performance. There's the Hardware Recommendations article that details recommended hardware specs.
But even this article isn't regularly updated by our end-users unfortunately, i.e. as developers, we're getting extremely little feedback in terms of what works, and what doesn't unfortunately. Still, people are coming here and complain about FlightGear not working for them asking us to fix it. Likewise, we've had a build server that regularly provides so called "nightly snapshots" that represent the latest developments all pre-compiled into a single binary, which is another thing that would allow end-users to get involved in testing -and providing feedback- without having to be core developers.
The main problem here is that as developers we cannot be expected to test/troubleshoot things that work properly for us, we literally depend on end-users getting involved, willing to troubleshoot things for us based on guidance that we provide.
Too much talking
Another common complaint expressed on the forum is "too much talking, too little materializing". You know what ? That's typically a phenomenon of people being unskilled. Not just that though. Unskilled and unwilling to learn new skills.
So they resort to talking instead, lots of talking. Trying to talk to the few people who actually have some skills. You can witness that in the FDM discussion thread: There's a ton of postings made by many people, and very few postings made by very few people who are obviously skilled an experienced.
So in simple terms what's happening there is this: Those who recognize their inability/unwillingness to learn something new, beg/nag/annoy others who already have those skills to donate their spare time according to their own priorities. Simple as that.
So this is typically a sign of people who are unskilled and unwilling to learn new stuff - so they beg others to do it for them, i.e. delegating responsibility to others, instead of shouldering it themselves, and being a pain in the butt in the meantime.
It's a lame excuse, i.e. talking instead of acting - because talking is so much easier than spending many hours reading something and making experiments, i.e. learning a new skill such editing XML files or working through tutorials.
And then you have those few people who actually have the skills required to implement what others are requesting - but they have typically very little spare time, because they're involved in other areas of FG, or maybe even because they don't have enough time to contribute to FG at all, due to RL.
You can usually tell quickly who belongs to which camp of people.
Then again, you have people like Thorsten, Philosopher or Gijs who have contributed hundreds -even thousands- of hours contributing to FlightGear. And they're typically the ones being asked to provide help and support in a 1:1 mentoring setup. Despite the fact that these very people also spent many hours creating resources (such as tutorials) to enable others to learn the very same skills they've acquired, by playing with "hello world" examples, experimenting a bit and working through tutorials and code examples.
It's "education", just that - education always pays off, no matter if it's a degree in real life, or if it's time spent learning a new skill, such as cooking or programming, 3D modeling or writing.
Successful contributors always seem to have understood that you need to be able to walk before you try to run. Many others didn't understand that, even if they were told so. We had one guy interested in "rewriting" the bombable addon, without ever looking into the code, without talking to flug (its developer) first. Kinda uninformed and stupid isn't it ?
If you want to participate in a F1 race, you need to understand the rules first - and better already know how to drive a car, right ? If you were to learn how to play golf, you'd better spend some first getting the basics straight, right ? You'd be kinda ill-advised to directly ask Tiger Woods to coach you, right ?
But that's exactly what's happening once people come here with a zero track record of contributing to the project, and without any obvious willingness to do some upfront work, and then ask folks like Thorsten or Philosopher to "coach" them, because they are "Tiger Woods" in FG terms
Kinda annoying if you ask me ... Honestly, instead of asking the pros to accommodate you, show some willingness to get started first of all. Especially at a stage where you still have zero clue about anything relevant apparently and zero interest in rolling up your sleeves to make some experiments first ?
My whole point was that we're all in the same situation at some point - your situation isn't any different. No matter if it's due to your skill set, limited spare time or limited hardware budget. All of us were once faced with at least one of these before. And like I've shown now, others are much more constrained than you are.
Yes, you can go and claim that this is about all the skills necessary - but that's simply not the point.
To be perfectly honest, I am not at all interested in learning Blender (3D modeling), I once had it installed but I didn't seem to have the mental capacity (read:patience) to use it any longer than 5 seconds without becoming crazy. As you can see in the canvas forum, others (including core developers) cannot stand Inkscape at all.
So when I needed help related to 3D modeling, I ask others -more experienced with it- to do this for me. In return, I volunteer my own time to accommodate them, i.e. personal networking. Likewise, I am not overly interested in FDM tuning, but I can help with other things. I am also not very interested in learning GLSL or effect development, but I am sure that I could ask Thorsten to help me here, because I helped him with other things.
You will find that this is how the project works generally. We have quite a few people giving "impulses" every once in a while, without necessarily contributing directly to the corresponding effort itself. You will find that I usually try to provide something in return whenever I leave a comment suggesting/requesting something - such as an offer to help with some specific feature or implementation detail. That's kinda the "glue" that keeps things together here. And that's all there's to it, really.
Of course, I also find it much easier to just make suggestions or requests than implementing something directly.
But that's simply not how the project works (or life in general). Not even for people who are core developers and intimately familiar with the project. You'd be surprised at the number of good comments and suggestions made by long-time core developers, that receive little or no feedback from others in return to good, informative and well-written suggestions. Zakalawe is encountering this regularly on the devel list, and still keeps on contributing - handling many ideas on his own instead.
Usually, there's a handful of people interested in exactly the same things as you're. Now, you could do yourself a favor and read what they've written and actually find a way to team up with them.
Some of them may be interested in XML, 3D modeling, texturing or scripting - whenever you team up with others, only need to complement each other.
It would only take 20-30 minutes of your time to get this started, i.e. send out PMs to others and find a way to make yourself useful to them.
So what I have laid out here is a way to make yourself useful to others, and actually cause the changes you're looking for, without having to do all the work yourself.
Optional Features
People go through great pains to implement new stuff in optional ways. Replacing the default renderer by ALS would be way easier than implementing ALS in an optional way such that aircraft-defined effects work in both frameworks. Replacing Basic by Advanced Weather would be much easier than to come up with a common, 'neutral' interface to which any weather system can talk to. Writing and maintaining a single terrain shader would be much easier than write and maintain three quality levels which have different demands on the GPU.
Ripping out the default rendering pipeline in favor of Project Rembrandt would have been much easier than supporting multiple rendering pipelines.
Possibly a quarter of developers' time goes into implementing stuff in such a way that you can run FG with essentially the options of 1.9.1 or that you can scale back performance needs. We don't even delete the legacy 256x256 terrain textures which duplicate hires textures, so if you have low GPU memory, you can go to the global texture scheme, delete the Textures.hires folder and run with very low texture resolution on the terrain.
In pretty much every discussion on the devel list, having a fallback mode whatever new feature is implemented featured prominently.
The only thing that really works differently between 1.9.1 and 3.0 on a legacy system is that 1.9.1 will work right out of the box, whereas for 3.0 you will have to configure some to make it work.
Discrimination ??
This is one of the more common thoughts expressed on the forum, so here's our take on it:
Users are essentially getting FG for free, but though most people with lower-end hardware can run the older versions just fine and can still get scenery and aircraft for versions like 2.6, some feel discriminated against because they can't run all the newest developments on outdated hardware and don't feel up to changing the config a bit to make it at least run? Seriously?
That's a slap in the face of all people in the world who really have to suffer from discrimination.
There isn't any form of discrimination taking place: not even manufacturing a Ferrari or Porsche qualifies as discrimination just because I cannot afford buying a Ferrari in cash - and FlightGear is far from being a high-end product.
FlightGear is very much like shopping: you get what you can afford, but you aren't discriminated against just because there's certain products like salmon or caviar that you cannot afford to have every day, you simply don't use/buy them. Just because your cable TV offers payTV doesn't imply that you have to use it, or that you are "locked out" by it. The whole discussion kinda seems like people complaining about the prize for "first class" tickets, even though they're not forced to even use certain features (like flying).
Some users tend to think that just because FG is free, that all its latest features also must be freely available to everyone - then, we would need to add $3k worth of hardware to each free download to make that work.
On the other hand, we do have a few users and contributors who have fairly recent hardware, for which the FlightGear default settings do not scale particularly well. They're asking us to provide more eye candy features, such as higher visibility, beyond just 30 km.
Consider FlightGear like a cell phone plan: it can certainly be used to make phone calls as is (even when using 90s-era phones), but if you want it to do other things (GPS, internet access, games, mapping, iPhone/Android store etc) - you simply need to have certain hardware - FlightGear is really just the "plan/contract/service/software" offered here (AT NO COST to you), it has nothing to do with the type of hardware that you've got access to.
In fact, as a piece of software, the program knows nothing about the hardware you have - so we need to make concessions and compromises to support commonly available hardware. More often than not, this process is based on what we, FlightGear contributors, have access to - i.e. it is people who actually get involved in testing and development that get to provide feedback.
And while it is true that some things need changing to better support older hardware, the majority of features that people are referring to in such discussions (Rembrandt, ALS, advanced weather, osgEarth) simply cannot be run on 90s-era hardware realistically, which has nothing to do with FlightGear. FlightGear is just a collection of technologies, including things like GLSL (shaders) or osgEarth - however, if not even these components can be run with old hardware, don't expect FlightGear to do so.
And as a community of volunteers contributing to the project, we typically only have access to 1-2 "devices" (computers) to test-run our code, so we depend on others to provide feedback. For instance, there are some of us who really have more than just a few computers, but testing and running FlightGear on such computers is also taking up time, and few of us actually do that regularly.
Some people are basically asking for hardware with "forward compatibility", because that's the main problem here: old hardware not being able to support certain features, i.e. pre-GLSL hardware not supporting shaders isn't exactly surprising.
Scaling Issues
Most of us do agree that there's an increasing number of features in FlightGear that require an unprecedented degree of "customizing" things for FlightGear to still perform on "old" hardware.
We are definitely facing challenging times when even people with 2gb VRAM, 12 gb system ram and quadcore CPUs end up seeing FlightGear crashing more often than not due to lack of resources. For most of us, this just means that because of our typically very powerful hardware, the problem is kinda "masked" for a while, and has been obviously for some time.
But don't forget it is the samurai coder way to make everything as efficient as possible, and make it run even on the toaster. That's not the case with terrain here, there is lots of room for improvement, right now terrain rendering is very inefficient and quite last century. An upgrade would not only make it run on toasters, but also give us almost unlimited distance and other underlying facilities. But it is a hard endeavor, perhaps one of the hardest.
And the problem is two-fold: startup defaults that may make certain assumptions (without fallback mechanisms), but also runtime usage of precious resources without providing a means to track CPU/RAM/VRAM usage across subsystems.
Even if you were to completely ignore the rendering side of things, there are algorithmic issues involved here - i.e. certain things would even be problematic in a purely "headless" mode - no matter if it's CPU or RAM resources that are burnt, and that's the kind of stuff that needs to be solved first.
Sooner or later we will need to tackle this (and it has nothing to do with AW/ALS or anything that Thorsten is working on).
Note that I am not suggesting that we should "aim lower" or settle for some unreasonable set of defaults, because that would be just as frustrating for people who actually do have the corresponding horsepower. Instead, we should explore options to make things increasingly runtime-configurable and entirely optional if necessary, so that a few lines of scripted Nasal code can dynamically query the runtime environment for certain traits (number of CPU cores, amount of RAM/VRAM, GL/GLSL support) and automatically not use certain code paths that are known to be problematic for people without such hardware.
The effects framework seems to be half-way there because it supports conditions and can use different fallback mechanisms - but in other areas, this still needs quite some work. It is however valuable work that would help us in other areas, such as supporting runtime-switching of aircraft, re-initialization - or re-targeting FG.
As has been said earlier, it is currently possible to run FG 3.1 on extremely old hardware - even on an Intel GMA netbook with very poor OpenGL support - but it takes quite a bit of tinkering, and may sometimes even require code changes. We've seen people on the forums who reportedly ran FG 3.x on computers as old as 8 years, and graphics cards as old as 6 years.
If I had to use really old hardware, I'd still go with Linux though, I have seen 90s era server hardware being extremely well supported by even a 3.x kernel, with rock-solid performance.
FlightGear-wise, I would also be inclined to use the latest & greatest and customize it heavily, and provide feedback if something doesn't work as expected.
However, keep your expectations reasonable.
Thorsten's work however has always been 100% optional and shouldn't affect people on older hardware, and it isn't feasible to "back-port" certain features like Rembrandt, AW, ALS or osgEarth - for the reasons mentioned above.
Response
So the whole discussion is really not about whether we should commit to run FG on legacy systems. The whole devel community is committed to that goal. The discussion is really about how straightforward this should be. Hooray evidently argues that all installation should default to legacy systems, the majority of the devel community has the trend to set the defaults to the assumption that you run on a present-day moderately powerful computer.
And what angers me personally is that there's just zero recognition that we go through all the pains of implementing new things optionally and keeping the legacy door open. I never seem to be dealing with people who say 'Hey, it's great that this still runs on my old XYZ system, all I had to do was...' I only seem to run into people who expect it to work out of the box, complain about growing harddisk needs of the installation, don't bother to read up on some config options and then complain that FG is only for rich people, that we'd ban users and similar nonsense.
So yeah, if you want to run present day software on a legacy system, what's wrong if you have to configure some yourself?
The whole development would really be much simpler if we'd do it the commercial way - we define system requirements, make sure the whole results fits into these, and if we add cool features we just raise them. We could get rid of plenty of legacy code, textures and such, get a more streamlined installation process, reduce the number of user-controllable options to something way more intuitive - there'd be plenty of goodies to that. Except we're not doing it.
I'm the author of a rather popular (several 100.000 downloads) introductory course to Tolkien's Elvish languages. I wrote this course initially in German, later changed to English. I made the pdf freely available for download.
There are undoubtedly people interested in Elvish who don't speak English well enough to understand the course. There are undoubtedly people who don't at all own a computer and can't hence read the course. There are people without internet connection who can't download it. So I've made a course that isn't really accessible for literally everyone, but only for those who have the technical means to access it.
In what way would that mean I am not fair? I made something freely available - some people can't get it only theoretically though - why does that argue I'm unfair? Where in this whole business is my duty that if I spend 1000 hours on writing something, I have to spend another 2000 hours translating into more languages / different formats to that *really* everyone can get it? Where does your sense of entitlement come from that if something is provided for free, it has to be provided in such a format that really everyone can use it, otherwise it'd be unfair?
If you take a 12 year old computer and try to install Windows 8, I doubt it would work. You might barely be able to make Linux run if you get source code for legacy drivers.
The answer to your question is, lots of new development happens because there's development on the hardware side. We can now do things which we couldn't do 10 years ago because graphics cards are more powerful, there's more memory, more processing power. Which means if you don't have new hardware, you won't be able to benefit from a large share of new development.
It's not that you couldn't get and run FG I presume - apparently the older versions run just fine for you - so you're in fact getting the product you want for free, the only thing you're not getting are the new developments - which you couldn't use anyway because they rely on new hardware. As for not being sure whether you can download aircraft for older versions - 30 seconds entering 'flightgear 2.4 aircraft download' into google would have led you here - we care so little about legacy support that the whole list for 2.4 is still up for download...
So the gist of this rant is in fact that you feel unfairly treated because FG development doesn't happen specifically for you and your requirements (I hold to my statement, and Hooray has even proven it - newer FG version do run still on old hardware if you configure some) but the defaults target other users. Well - guess what - they also complain and say 'this is so rubbish' if FG does not use all the performance modern hardware provides. So kindly stop assuming you're the center of attention of the devel community and accept that FG is developed for the average hardware a user would presumably have - if your system is much different from that average, either above or below, you need to tweak options.
Lack of Testing
The main problem here is lack of testing not lack of development. In fact, it is the progress in developing that is causing such issues for people like you on outdated hardware: If there wasn't any progress, things would stay as they are, and just "work". So the real problem is lack of testing, not by developers, but by end users willing to get involved in order to help us ensure that FlightGear also works on hardware that we don't have access to.
you don't need to become a developer to help us with testing. Even 3.0 should probably work for you if you use the instructions detailed in the article I linked to earlier. But obviously we cannot know what doesn't work as long as people don't actually help us testing and report back. Which is not just about you - it's a general problem.
That said, even regardless of outdated hardware, FlightGear would be in a much better shape with more testing applied, and with more considerations for backward compatibility - there's an increasing number of users wanting to run FG on different types of hardware, such as gaming consoles or even mobile phones - here, the current way of starting & initializing FG is extremely problematic. So there are some things that need to be teased out first.
This is not about applying "low" standard to all hardware - it's just about finding a common subset of startup settings that works for most people, so that the system can really "boot up" and add new stuff incrementally - kinda like a computer is booting (POST, BIOS, boot loader, real mode, protected mode, operating system, networking, GUI, hardware acceleration etc)
This is something that we don't currently do very well, but it would help us in other areas (profiling, benchmarking, even headless regression testing, runtime re-initialization (saving/switching flights & aircraft) etc), so it is a worthwhile thing to aim for, even for people who have access to the latest hardware.
But it's not going to happen over night, it will take patience and lots of testing and feedback - and keep in mind that the forum is not a good place for bug reoprts, a forum is about talking/debating, the issue tracker is a better place for such reports
We have various starting points and articles to help with various steps, but nothing fully dedicated to "just" testing. But the minimal startup profile should be a good starting point, and then it's primarily a matter of testing various settings and using the issue tracker to report things (or at least the wiki). Ideally, people would team up with others on similar hardware. Coming up with your own .fgfsrc startup files may also be helpful (documented on the wiki), so that "profiles" can be more easily shared & exchanged. Benchmarking-wise, people could exchange pre-recorded flights and/or flight recorder tapes to replay certain flights.
And then it's obviously helpful being able to interpret results, i.e. frame rate, frame spacing/latency, system monitor, built-in profiler. And accessing the log file in $FG_HOME would another thing that I'd cover in such an article.
Pretty much all of these things are separately covered on the wiki, so pointers are easy to provide, it's just a matter of adding a handful of paragraphs to link all steps together, and maybe add some screen shots.
To put it very bluntly: Currently, testing is one of the least popular occupations among our end-users, but also contributors - to many, this may seem like an issue that needs to be solved, and for which the project is to blame. However, we've had other areas were resources were severely lacking, such as certain documentation, or tutorials for new contributors and developers. Meanwhile, these issues have been addressed (often by very few people), however this usually meant that they're the ones to shape were things are going to some degree - I usually refer to this as "embrace the gap", by filling it what you consider important - i.e. "being the change you want to see". This is the key difference between people who come here and "whine" all day long (for months or even years!), and others who simply roll up their sleeves and accept the challenge to fill some void with their own ideas & contributions.
In the context of "testing" and community networking, this could actually mean that even just a handful of dedicated end-users could significantly affect FlightGear development, simply because there's really not a lot of testing going on otherwise - i.e. it would currently take just a few testers to basically dominate or even "own" this feedback category.
And as mentioned elsewhere, it is something that will be useful for a number of related efforts, even though it may not be obvious to most non-developers.
Nobody here is asking you to become a programmer or aircraft developer to help us with testing.
To be honest, most of us fully agree that FG's support for older hardware has not really improved very much during the last 2-3 release cycles, and we find it a pity too.
But to me, this is not about some outdated aircraft - it's a core problem, that should and could be tackled, and people like you (on old hardware) could actually help with it, e.g. by contributing to the issue tracker whenever something doesn't work as expected.
IF we had more people like you contributing to the project actively, certain things would not go unnoticed. For example, I actually contributed a tiny little patch 2-3 years ago which was intended to provide better diagnostics for OpenGL/shader issues. It was trivial, but it actually broke FG for people who didn't have hardware supporting shaders, i.e. people with old hardware - like you. I never noticed anything, and neither did any core developers - because we all had sufficiently modern hardware. Then again, we cannot all have dozens of computers to test FG on, that's where folks like you come in.
I would LOVE to have 20+ people here with really outdated hardware who regularly test-run FG on such hardware and provide feedback via the issue tracker. And I would volunteer my time to help ensure that things are kept working on such platforms. But so far, we have very few folks actually interested in contributing in this way to the project.