The PC compositor-layer work (the Direct3D 11 proxy, its installer, its notes) now lives in pc-streaming/, clearly
separate and marked experimental, so the main project is the Steam Frame build and the fixes that help it. The PC
layer can't change the Steam Frame's home (the Steam Frame renders it on the headset), and this keeps it from
crowding the Steam Frame release while preserving it for a tethered PC headset.
The shared Windows renderer support (src/, behind #ifdef _WIN32 / FRAME_HOME_PC) stays put: it only compiles into a
PC build and never touches the Steam Frame build. Build and README references updated to the new paths.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
On the Steam Frame a layer inside SteamVR's compositor draws the home where it would draw Aurora, so the home is the
environment itself: at boot, during game loads, behind the Steam menu, with the controllers and passthrough, and it
steps aside for a game the instant it opens. On a PC this was faked with SteamVR's home-app slot and a flat 360 photo
in the gaps, which launched and handed off like an app and showed a picture, not the live home. This does it properly
on any PC that runs SteamVR, the Frame's way:
- Windows: the compositor is Direct3D 11, so the layer is a proxy d3d11.dll beside the compositor (layer/
frame_home_layer_d3d11.cpp, built from the .def that forwards every other export to the real d3d11.dll, kept as
fh_d3d11real.dll). It wraps the compositor's device, finds Aurora's draws by their shader bytecode and draws the
home over the sky, leaving the floor and stars off; everything else passes straight through. Pure pass-through in
any process that isn't vrcompositor.
- The home's frames cross from Frame Home (Vulkan) to the compositor (D3D11): the layer owns kSlots shared textures
and hands Frame Home their NT handles over a named pipe; Frame Home imports them (VK_KHR_external_memory_win32) and
renders into them. No cross-API lock — a slot is published only once the GPU has finished it and the four rotate,
as on Linux. The shared State stays Frame Home's.
- The Environments panel runs frame-home --system and keeps it alive (one at a time, a pid file across panel
restarts), the same systemEnv path as the Frame. The installer places/removes the proxy and marks the layer with a
root/layer folder, in place of the old home-app registration and background pictures.
- Safe like the Vulkan layer: no home, or one stale over half a second, and the compositor draws Aurora as usual;
the layer turns itself off after two unhealthy compositor starts, and root/layer/off turns it off by hand.
Linux keeps its Vulkan layer (unchanged). Verified without a headset on the null driver: the proxy loads and wraps
the compositor without crashing, recognises Aurora's shaders, and the frame hand-over completes (Frame Home connects,
imports the textures, renders). The compositor only draws the environment while presenting to a headset, so the final
on-headset image is the one step the null driver can't exercise.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- frame-home --install/--uninstall and frame-switcher --install/--uninstall check for SteamVR's server first: on
Windows, connecting as a utility started SteamVR. Not running: exit 3 and the installer writes SteamVR's config
files, as on the headset.
- frame/payload: Frame Home, the panel, fenv-tool and the compositor layer built on the Steam Frame from this
source (installed there; locomotion tests 0 failed).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- src/home_platform.h: what Frame Home and the panel need from the system (paths, finding and stopping each
other, running a tool, restarting, priorities) for SteamOS, Windows and Linux PCs. On a PC the environments are
Frame Studio's My Environments; Frame Home's own files in %LOCALAPPDATA%\Frame Home (Windows).
- src/openvr_loader.cpp: a PC build finds SteamVR's own OpenVR library at run time (openvrpaths.vrpath), so it runs
on any PC with SteamVR; Vulkan through volk. CMake: FRAME_HOME_PC (default on Windows and x86-64 Linux); the Steam
Frame build is unchanged.
- Windows: Frame Home is SteamVR's home app; SteamVR's classic environment shows a 360-degree picture of the current
home from its spawn (frame-home --panorama --spawn, made by the panel when the home changes) instead of Aurora
while Frame Home starts. Linux PCs: the Steam Frame's compositor layer, as on the headset.
- frame/pc: install-frame-home-pc.ps1 (+ .bat): online through SteamVR's API or offline in its config files; the
SteamVR settings it changes are saved and restored exactly on -Uninstall (tested in a sandbox both ways).
frame-switcher --uninstall. Studio: Properties > Headset > This PC installs it from pc/ beside Studio.
- Packaging and CI: pc/ in the Windows x64 and Linux x64 Studio downloads; FrameHome-PC-windows-x64.zip.
- Thumbnails come from where Frame Home starts you (the first spawn, eyes 1.6 m up): Studio's saves and the
panel's (frame-home --snapshot --spawn).
- docs/pc-steamvr.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
src/fenv_bundle.h: a ZIP of bundle.json and the .fenv files stored as-is, copied
in pieces (zip64 from the start when 4 GB or more). Write, read the manifest,
read one environment's fenv.json + thumbnail in place, unpack all or one
(.part then rename, checksummed; never replaces a different file: "name 2"),
validate.
fenv-tool bundle / unbundle, and info lists a bundle's environments. The
switcher unpacks bundles dropped into envs/ into their environments and
deletes them (frame-switcher --unpack-bundles does it at once). The installers
copy .fbundle files alongside .fenv; only a .fenv sets the one shown.
tools/bundletest checks it against real environments (--big: past 4 GB).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- ImGuizmo is compiled with -fno-strict-aliasing on GCC/Clang: its type
punning let Clang for x64 turn gizmo drags into NaN transforms
- 32-bit: the .fenv packer keeps LZMA within a 32-bit address space (saves
failed with out-of-memory); failed saves are logged
- std::to_string of file times and the 32-bit descriptor handle cast compile
on every standard library
- Linux fonts: Noto Sans, then Liberation Sans, then DejaVu; the Play/Pause
button sizes to its label; macOS fonts are rasterized at Retina density
- self-test stages allow at least 3000 frames (software GPUs draw ~30 a second)
- headset payload rebuilt from this source
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Frame Studio now builds for Windows (x64, x86, ARM64), Linux (x64, x86, ARM64)
and macOS (Apple Silicon, Intel):
- studio/platform.h with Win32 and POSIX implementations (dialogs through
tinyfiledialogs on Linux/macOS), a GLFW window beside the Win32 one, and a
platform-neutral frame pacer
- MoltenVK support in the renderer (portability enumeration) and bundled in
the macOS app
- 32-bit builds: large-address-aware, LZMA packing within a 32-bit address space
- unaligned file reads in the loaders go through loadUnaligned (no UB)
- scripts/build-studio.sh, studio/build_windows.bat [x64|x86|arm64],
cmake/llvm-mingw.cmake, and a GitHub Actions workflow building every target
Frame Home installs without Studio: frame/install-frame-home.{sh,ps1} and
"Install Frame Home.bat" (packaged as FrameHome-installer.zip).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
