PorkrollPosadist [he/him]

CNC machinist, absentee mastodon landlord, jack of all trades

Talk to me about astronomy, photography, electronics, ham radio, programming, the means of production, and how we might expropriate them.

  • 0 Posts
  • 6 Comments
Joined 4 years ago
cake
Cake day: July 25th, 2020

help-circle
  • None.

    X-Plane comes close to FlightGear. It has far-superior visuals. fully functional glass cockpits like the Garmin G1000, and simulated ATC, but the vast array of community-made planes available in FlightGear still kinda seals it for me, despite the jank.

    FreeCAD has its pain points. Software like Creo Parametric is much more robust in a lot of ways, but I literally cannot run it on Linux (no mouse-wheel zoom in WINE, slide show in QEMU). Fundamentally, they are similar enough, and my work primarily takes place on a component level so I can live without the streamlined assembly workflow. Also, FreeCAD doesn’t cost >$2000, and can still do FEM analysis and computational fluid dynamics. Maybe I could find a crack for SolidWorks and try that out, but it takes a long ass time to learn a CAD system proficiently.

    Everyone who learned on Photoshop says the GIMP interface is weird, but I learned on GIMP and can say the same for Photoshop.

    Games are the only exception, but games aren’t fungible. Minecraft is not a substitute for Dwarf Fortress. CS:GO is not a substitute for Unreal Tournament.


  • Basically, on Fedora you are a guinea pig for whatever new tech Red Hat (now IBM) is considering rolling out. It is a well polished distro and I have set it up on several people’s computers, but they will be among the first to just foist a whole new replacement subsystem on their users. Can be interesting if you like experimental shit (and what comes to Fedora tends to stick around [i.e. PulseAudio, systemd], unlike a lot of the shit Canonical has tried to introduce [i.e. Upstart, Mir]). Can be a major headache if you are trying to use something which requires iptables and they have jumped into nftables with both feet (for instance).





  • The Distro isn’t super important, since Valve started shipping their own runtime (for Linux ports) and Proton (for Windows games). Anything modern outside of the strictly free-software distros (things like Ututo, Guix, etc. which do not ship proprietary firmware or drivers of any kind) will suffice.

    There are a few different approaches to playing Windows games. Some have direct ports. Games like Doom, Quake, were open-sourced a long time ago and have dozens of ports with all sorts of features. Other games, like CS:GO, Kerbal Space Program, X-Com: Enemy Unknown, etc. are not open source, but have ports produced by either the developer or the publisher. A LOT of indy games have ports available, and most modern game engines like Unreal, Unity, Godot, etc support Linux targets (whether the publishers give a shit is another story.) These typically target the Steam Runtime (a collection of specific versions of graphics, audio, and auxiliary libraries that Steam will install). These libraries are also provided by distributors, but the distribution libraries will typically be newer. This is normally a good thing, but commercial ports don’t receive frequent updates and are likely only tested against the Steam Runtime.

    If there is no port available, the next option is Wine. Wine is a Windows compatibility layer which is capable of loading Windows PE format executables on Linux and dynamically linking them to a large collection of substitute DLLs which implement Windows functionality on top of Linux. Proton is the version of Wine shipped by Steam, with a bunch of tweaks specifically focusing on graphics performance. Most of the time, games will work in Proton, but there are a handful of cases where they work in Wine/Wine-Staging but not in Proton.

    If the game requires an anti-cheat component, it will almost certainly not work in WINE/Proton, because the whole basis of getting Windows games to work on Linux operates using the same mechanism as cheats: replacing “genuine” components of the Windows operating system with 3rd party code to intercept system calls and do something other than intended.

    A much more complicated route would be to set up a virtual machine. A virtual machine is a full blown PC-emulator, except since the host machine shares the same instruction set as the guest, it is a lot faster. This is not enough not yield good performance in games though, because games also require direct access to the video hardware. To do this, you need a SECOND graphics card for the guest operating system, then you can try to configure PCI-e passthrough (so the video driver in the guest OS talks directly to the video hardware). This is probably the most complicated approach, but you end up running genuine Windows virtualized on real hardware. In addition to the second GPU, you need to make sure you have the overhead in CPU / RAM / storage to run multiple operating systems concurrently such that gaming performance won’t be substantially impacted. Additionally, you probably need a second monitor if you want to interact with both the guest and host operating system simultaneously.

    Finally, if none of that works, it may be worth looking into whether ports for other platforms exist. If you struggle running a dated Windows game in WINE, you might have better luck emulating a release for PS2/3, GameCube/Wii/WiiU/Switch, etc. The state of Nintendo platform emulation in particular is phenomenal, and it is trivial to increase the video resolution beyond what the official hardware supports if your machine has the horsepower for it.