GamePad: A New Open Source And 100% Linux-Dedicated Game Platform
Toni Jarels
Questions: Are my X-Plane (non-STEAM version) and aircraft licenses independent of platform or do I need to repurchase? Which GPU's support Linux best, AMD or Nvidia? Which CPU's, AMD or Intel? Are there any other issues that I might need to consider?
I'm not sure which brand GPU has better Linux support, however, I can tell you that my GTX 1080 Ti gets better performance in X-Plane in Linux than in Windows 11 last time I used X-Plane 11 in Linux which was around 4 months ago. In Vulkan mode I got 38 fps in a certain scenario in X-Plane 11 in Windows and 45 fps in the same scenario in Linux. I'm not sure which brand CPU is better supported in Linux but then again I'm getting better performance in Linux than in Windows in X-Plane 11, and in that scenario I was CPU limited. However, as for issues you might need to consider, some addons won't be compatible with Linux or have issues with Linux, the main reasons why I went back to solely Windows 11 and gave up on dual booting Windows 11 and Linux Mint, despite the better performance in X-Plane 11 in Linux on my system. For example, Traffic Global, is not compatible with Linux. I had a weird issue in Linux where shortly before touchdown, in the FlyJSim 727 and 737, there was a huge frame rate drop for several seconds, like going from a capped 30 fps down to about 15-17 fps instantly, and then when I cleared the area of the huge frame rate drop, I was approaching like in fast foward motion for a few seconds, which made it hard to control the aircraft during approach. Also I couldn't get the Sparky 744 to work in Linux as I would get a parsing error after it loaded. I also couldn't get the FlyJSim Q4XP to work with Linux. Also XP Realistic Pro is not compatible with Linux.
You'll have fewer problems in general OS upkeep with AMD because their drivers are open source...though of late that has been less of an issue, especially w/ a code like XP that doesn't particularly push boundaries in terms of graphics API calls. As is par for the course with Linux land, if you stay on a stable distro (eg boring old debian), you will generally be safe. Pushing to bleeding edge versions might let in the bugs. So if beta testing software is your jam, you can have your toast and eat it too, if wanted.
NV recently opened up a small fraction of their driver base but not to an extent that will provide a short term benefit. When they work, which is most of the time, their proprietary drivers are just fine.
Single-thread perf is still a good metric for what CPU to go with. Most CPUs you can buy these days will have more cores than XP knows what to do with. I recall a LR dev saying once that their long term goals would benefit from 8 cores, but that probably won't be an issue for a couple more years. So a fast 4 core CPU will probably be fine...though there are addons that might push that from time to time. 8 to be safe and future-prepared?
Also most hardware is perfect. You might encounter some consumer products like TV cards or obscure bluetooth dongles, ... to be not well supported (You can try to find information about it, but mostly you should just try yourself).
For people coming from Windows it is worth noting that hardware that comes with a kind of controller-app (for example controlling LEDs on our keyboard, some joystick configurator or my trusty M Panel) will often not be supported on Linux unless somebody programmed something. More and more Windows software can be run on Linux via Wine/Proton near-natively but for this class of software (dealing with hardware directly) this does often not work. Using a virtual machine with exclusive hardware access (VirtualBox has a nice UI for that) might work for your use case.
Both big vendors AMD/NVIDIA either have (AMD) or have announced (NVIDIA) to have their drivers open-source. The experience with AMD open-sourced in the past (!) seems to have not been as good as anticipated for some people (that is really only hearsay! You might be perfectly fine, too).
Also the audio stack might be interesting. We currently are in a huge switch from pulseaudio to pipewire there. This might be of interest if you are using online networks like VATSIM or need screen sharing.
All (good) distros should have an USB-bootable live environment. After you have installed X-Plane somewhere on your hard disk with one distro, you can just boot into a live environment, (install your graphics drivers if needed), mount your hard disk and try X-Plane with that other distro. (make sure to clean the Vulkan shader caches when switching environments).
As for the best gaming distro, It most probably has been Ubuntu/Kubuntu/Xubuntu 20(!).04. I expect that to change because of some decisions they took with their latest release, but it is currently unknown where the crowd is moving. Steam has based their newest SteamOS (v3, not released yet) on Arch (before it was based on Ubuntu).
Linux desktop is currently experiencing changes on multiple fronts. We have X and Wayland, pulseaudio and pipewire, OpenGL and Vulkan. This makes it currently harder for vendors to support the Linux platform well, leading to some problems. Linux has always been about having the choice, but in the gaming field we are so negligible (albeit currently growing) that this really hurts us.
Thanks@flightwusel. I am currently using Mint 19.1 on a second self built, non-gaming computer that is more than 15 years old. Works great. I keep all my poh manuals, charts and flight planning info on it to reference while I fly. I installed Peppermint on a newer HP computer to replace Windows 7 because Mint kept crashing it (looked like graphics issues). The latest stable Mint distro will probably be the one I try first. I would rather get AMD because they run cooler but Michael Brown of XForcePC does not seem to think it plays as well with X-Plane as Nvidia does. I will have to give that some more thought. Thanks again to everyone who provided input.
He did say that a while ago but it was also before LR was publicly known to be submitting fixes to the Zink translation layer in Mesa. Probably do hold your breath for a bit longer until 12 comes out and don't give up on AMD yet. I mean, Vulkan began life as an AMD project...it better work well at some point!
Well, if I was a Windows user, I'd really consider switching, too. Win 11 may be totally fine under the hood, but the UI changes they've implemented (and which can't be turned off) are simply atrocious.
In the FWIW department, I've found ZorinOS to be a pleasant distro in terms of mimicking Windows. I pine for more fidelity in the "explorer" part of the file system, and really don't like the fact that file dates get interpreted sometimes as just "today." ? Just offered as an option - I have yet to convert to Linux. Some day, some day.... ?
a bit late to the party, but I wanted to add my 2... I've have exclusively flown XP on Linux for a few years now and have had no major issues. I had to return an add-on plane I bought because of the case sensitive / insensitive issue (sloppy devs on the add-on deleloper side here, this could have been an easy fix, but they weren't interested), but apart from that I've found Linux-compatible products for most plugin functionality that I care about (Linux Mint 19 currently). I've had no issues with add-on scenery (both free and payware) and the add-on planes I'm using (rotate md-80, toliss a-319, p-51 mustang, zibo, embraer 1X5 and quite a few more).
I'd also recommend going with an nvidia gpu (1070ti on my end), it works fine with my amd-based gaming motherboard and has no issues pushing 30fps (my hard limit for XP to reduce power consumption during long haul flights) in most situations at 2500x1660 on my 42" LG TV.
in late 2013 I started experimenting with what is possible using JavaScript/WebGL (coming from a computer engineering - C++/Java university background). Over time it grew into a game engine and then this game, as I worked on it in my free time next to full time jobs and more recently, contracting work.
So it is entirely custom code (the only library used is RequireJS to load the JS files themselves), and I made all the assets as well (models, textures, music, sound effects (using some free CC licensed sound samples as a base) - you can find details in the "About" page in the game. As a result, the engine features and asset quality are rather modest.
My goal is to create a fully fledged 3D space sim with procedurally generated missions that can be played on any computer with a modern browser. I am going for more of a softcore sim feel rather than an arcade one (there are many arcade options these days, but I prefer the more serious, elaborate controls of sims, without the time/hardware investment needed for something like Elite: Dangerous - which also doesn't run on my linux machine)
Please note! The download size for the game can be significant (tens of MBs - depends on graphics settings and the mission being loaded), so I do not recommend trying it with a plan where you pay based on the amount of data!
You can check out the code at -armada. Feel free to fork it - since it is 100% client side code, you can just throw it into the public HTML folder of your server (e.g. Apache) and it should work locally right away. Then you can use the built-in editor in the tools folder (localhost/the_folder_you_put_the_game/tools) to see how the game data files are organized, play with them (to apply the changes just hit export and then overwrite the original with the exported file in the data folder). Note that you cannot create or export missions or edit config/settings from the editor (as of now)
Since this is a long project and I regularly revisit and update parts of the codebase that I might have not touched for a year or so, I try to keep it organized and nicely commented even if just for myself. However, this is not the number one priority, so there are parts of the codebase (which at this point grew above 60,000 lines) which are in terrible, terrible shape. I believe the best example of this currently is the code for the HUD.
7fc3f7cf58