Newest Linux Gaming Predictions for 2023
Prediction: Valve will cleanup the technical abomination which is the current steam client: clean 64bits (yeah, the core is still 32bits...), libdl-ing all its system deps (yeah, it is still statically loading libgl...), static libstdc++ and static libgcc to avoid those horrible ABIs, shell scripts with program helpers and conservative usage of command options and not bash scripts using command niche options (often gnu only, or alternative breaking, for instance alternatives of the &quot;official xz&quot;). Ofc, beyond compile-time OS abstraction tables of functions, proper runtime fallback tables of functions (wayland-&gt;x11, vulkan-&gt;GL-&gt;CPU), but since libcef (the steam client is moving to libcef) is blink, they don&#x27;t do anything, google seems to do everything here (hope I am wrong).<p>Ofc, all game engines will be coded properly the same way. It seems unity3D is doing exactly that (but their vulkan3D backend seems far to be on par with their glcore backend).<p>Elephant is the room: c++ is not mean for binary-only games on elf&#x2F;linux since the static libstdc++ does not libdl (dlopen&#x2F;dlsym&#x2F;dlclose) its system dependency (unless it was fixed by c++ gcc devs and I missed it). absolute truth: c++ syntax has a toxic complexity, not to mention its absurd and grotesque _very few_ <i>required</i> compilers in size and complexity.<p>And of course: Silksong, Half-life 3, dota2 out of beta and more native AAA (irony).<p>I don&#x27;t talk about proton, which does just displace the QA which should be done by the game devs on native elf&#x2F;linux to the &quot;proton devs&quot; (probably a money sink hole for valve) which have to deal with the massive bloat and kludge, msft grade (yeah...), of its code and SDK. It would be more reasonable with a lean build of wine(win64 core)+only vkd3d(dx12-&gt;vulkan), but I guess few to no games would run on that. Heard proton has straight copies of windows components... which would make things even worse.