Cyd asked what it would take to run on Linux. The answer is filed rather
than acted on: we are mid-playtest, and this is a decision for the end of
it.
Proton is the recommendation. The build is 32-bit fixed-function D3D9,
which is the most-travelled path Proton has, and Valve keeps i386 alive
in the Steam runtime containers specifically to carry it; Wine 10 fixed
child-window Vulkan rendering, which is the one thing that would have
stopped the cockpit dead, since the 3D scene presents into a child STATIC
with GDI panes clipped over it. Deck Verified is achievable from a
Windows-only build and is what comparable Win32 titles ship.
The native port is scoped in the doc rather than dismissed, because the
engine is more portable than it looks: RP is clean C++, MUNGA is ~90%
clean, single-threaded, with one timing seam and one file seam already
named. What stops it is mechanical and total - 1,800 of 1,844 include
lines cite a filename in a case no case-sensitive filesystem will find -
and then strategic: the wire format and .RES carry size_t under /Zp1, so
a 64-bit build silently changes the protocol while a 32-bit one targets a
runtime Valve is walking away from.
Five things need doing to the Windows build either way, and they are all
improvements to it on their own: the Dynamic Lighting mirror imports
windowsapp.lib statically, so its careful try/catch degradation never
runs under Wine - the image fails to load first; the plasma window and
the exploded MFD view are extra top-level windows, which is what gamescope
handles worst; the viewscreen relies on the stock STATIC proc returning
HTTRANSPARENT for mouse fall-through rather than saying so; the 1080
canvas downscales 1.5x on the Deck, against a 9px legibility floor; and
the front end is mouse-driven, which Deck Verified will not pass.
Nothing here has been run on Linux. The first step when this resumes is
an afternoon with a Linux box confirming the child-window Present, before
anything is promised.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>