Library: a game's own madeira.cfg lines (Game details › This game's c…

[bahacan16]

…onfig)

Problem

Every runtime switch lives in one file, Documents/madeira.cfg, so it applies to every game. Trying a switch for one game means editing the file before that game and undoing it before the next. Real cases from device testing:

• God of War (2018, D3D11) ran out of memory on New Game (texture memory 4 GB). It reached gameplay with dxmt = d3d11.mipClampBC=1 (textures 4051 MB → 1050 MB) and env.WINEDEBUG = err+all,err-virtual,fixme-all (95 % of its log was one fixme). Neither should apply to other games.
• Ghost of Tsushima (D3D12) was tuned with D3D12 runtime keys (fence-chain, async-submit, dxil-tess-max-factor) that other D3D12 games do not want.

There is also a bug in how dxmt reaches DXMT: ContentView turns dxmt = a=b;c=d into a=b\nc=d. DXMT splits DXMT_CONFIG on ; only (src/util/config/config.cpp, str::split(confLine, ";")) and a newline is not whitespace to its line parser, so two options become one option with a broken value. Only a single option survives today.

Change

• LibraryEntry.config (optional, so older library files decode): the game's own lines in madeira.cfg's syntax.
• Game details › Advanced › This game's config: a navigation row (showing "None" or "N settings") that opens a monospaced text editor. The text is saved with the entry like the other fields.
• MadeiraConfig.applyGame, called from LibraryEntry.applyEnvironment on every library launch (Dock launches included): when the text sets anything, it is written to Application Support/madeira-game.cfg and MADEIRA_CFG_GAME names that file; otherwise the variable is unset and the file removed, so one game's lines never leak into the next session. A launch from the developer interface clears it too. The launch log gets a [game-cfg] key=value ... line.
• build/madeira_cfg.h: the line scan moves into madeira_cfg__scan (no behaviour change for madeira.cfg, BOM handling kept), and madeira_cfg_get scans $MADEIRA_CFG_GAME after madeira.cfg (or the legacy files), so a key set there wins. madeira_cfg_int, madeira_cfg_bool and madeira_cfg_sync_engine follow automatically. This covers every key the native side reads (ntdll, wineserver, madsync, winemetal, the D3D12 runtime through MadeiraCtl, the converter).
• WineProcessBridge.m: the game file's env.NAME = value lines are exported right after madeira.cfg's and before the fastsync default, so they win and a game's env.MADEIRA_FASTSYNC is respected ([madeira-env] game NAME=value in the log).
• ContentView.swift: dxmt options from madeira.cfg and from the game's lines are split on ; and newlines and joined with ; into DXMT_CONFIG; the log names each source. This also fixes the separator bug above for madeira.cfg alone.
• FPSOverlay.swift: the F pill's initial state reads the game's fence-chain before madeira.cfg's, matching what the D3D12 runtime uses.
• MadeiraConfig.parse is factored out of all() for the game file.
• ConfigCatalog.generated.swift regenerated (one new row, env.MADEIRA_CFG_GAME, marked as set by the app).
• docs/LIBRARY.md describes the section; tests/host/check-frontend.py's MadeiraConfig stub gains applyGame and checks that a launch hands the lines over and a launch without any clears them.
• tests/host/check-cfg-game.py (new): compiles the production madeira_cfg.h and checks game-wins, fallthrough to madeira.cfg, last-line-wins, BOM + CRLF, a missing or empty variable, and the legacy layout; it also checks the export order in the bridge and the ; join.

Evidence

From the fork, where the same mechanism has been in use since late September (iPhone 17 Pro Max, iOS 27):

• God of War reached gameplay with the two lines above in its own file, while other games kept the defaults.
• Ghost of Tsushima: two DXMT options joined with a newline (dxgi.customDeviceId=2544 and d3d11.metalSpatialUpscaleFactor=2.0) arrived as one option (Found config env: dxgi.customDeviceId=2544\nd3d11...), DXGI reported device 0 and the game's GPU check failed ("Unable to find active GPU"). With only the device id in DXMT_CONFIG the same build passed the check (NVIDIA GeForce RTX 3060 (active)), which confirms the separator diagnosis.
• python3 tests/host/check-cfg-game.py and tests/host/check-cfg-early-docs.py pass.

Notes / risks

• Keys the app itself reads in Swift at launch (pool, wx, d3d9, desktop-size, ...) still come from madeira.cfg only; dxmt and the F pill's fence-chain are the Swift readers that look at the game's lines. The footer says "wherever the runtime reads it".
• Keys read once per app run (for example inproc-sync, which wineserver keeps for the whole run) only take effect if that game is the run's first session, as with madeira.cfg today.
• madeira_cfg.h is header-only and compiled into several libraries; they need a rebuild for the game file to apply on their side (ntdll unix, wineserver/madsync, libdxmt_unix.a for winemetal's MadeiraCtl op 2, the converter service). Until then those components simply ignore the game file.
• No new Swift file; project.pbxproj is unchanged.
• tests/host/check-config-catalog.py passes with the dxmt/wine/FEX submodules checked out at the pinned commits.

---

🤖 Generated with Claude Code

Claude-Session: https://claude.ai/code/session_0189oLHghpaYKLk4f786a6bc