diff --git a/CLAUDE.md b/CLAUDE.md index 07eebdd..95d093c 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -59,7 +59,7 @@ There is **no single shared desktop/display for video** — unlike the other noV - `is_running(name)` does the same full teardown **lazily** if the game process exited on its own (quit or crash) — it won't leave an idle Xvnc/websockify pair holding a slot forever just because nobody clicked Stop. `render_page()` calls this for every tracked game on every load, so the slot count and each row's status stay accurate without polling. - Each running game's row shows its own "Open Screen" link (only while `Running`) — a plain top-level link straight to that game's own noVNC URL (`https://:/`, opens in a new tab). Deliberately **not** an iframe — see Audio below for why. - Per-game install progress (`install_state`), start errors (`game_errors`), and the running-process table (`running_procs`) are all guarded by one `threading.RLock` (reentrant — several code paths call `is_running()` from inside a block that already holds the lock). The page keeps itself current via `setInterval(refresh, 3000)` (client-side JS, not a server-driven `` — that would navigate the page and kill the persistent audio connection, see Audio below), so a crashed/exited game's slot shows as freed within a few seconds without ever reloading the page. -- **Manifests on the share today**: `stuntcar` (DOSBox), `monkey`/`monkey2`/`atlantis`/`indy3`/`tentacle` (ScummVM). `t7g` still has no manifest and won't appear on the setup page until one's added. +- **Manifests on the share today**: `stuntcar`, `duke`, `dn3d` (DOSBox), `monkey`/`monkey2`/`atlantis`/`indy3`/`tentacle` (ScummVM). `t7g` still has no manifest and won't appear on the setup page until one's added. `duke`/`dn3d`'s zips aren't the pre-existing ones under `Games\` — they're re-zipped copies of real played installs found under `MiscOS\MSDos\games\`, uploaded alongside those source folders (`zip_path` points there, not into `Games\dosbox\`); see `TODO.md` for how that comparison turned them up, and a known audio gap specific to these two (video confirmed working via screenshot, but their carried-over `duke3d.cfg` doesn't seem to have working DOSBox-SB16-compatible sound settings). **Playing a game — two overlapping paths right now**: 1. The setup page's Start/Stop buttons (above) — the current way, works for any manifest-driven game, gives it its own screen, and is capped at 10 concurrent. diff --git a/TODO.md b/TODO.md index 1b8ae6b..c54c889 100644 --- a/TODO.md +++ b/TODO.md @@ -171,3 +171,31 @@ `sampleRate`/`registerProcessor`) that force-feeding a simulated 4.3s burst leaves only ~85ms actually queued afterward, instead of growing unbounded. Propagated to both the `docker-common` canonical copy and this project's own copy, per the usual convention. + +- Added manifests for `duke` (Duke Nukem 3D, unregistered shareware — confirmed via + screenshot, "UNREGISTERED SHAREWARE" watermark and the nag screen, despite the folder name) + and `dn3d` (Duke Nukem 3D: Atomic Edition), both real DOS Build-engine games, both DOSBox + manifests. Sourced from real played installs at `MiscOS\MSDos\games\duke\`/`dn3d\` on the + share (found by comparing that directory against `Games\`, which turned up several + installs — including these — not present as zips anywhere) rather than the existing + `Games\` zips: these are raw, unzipped folders (with real save games, `duke.rts`, etc.), so + they were downloaded, re-zipped locally with the usual `/` top-level-folder + convention, and re-uploaded as `dn3d.zip`/`duke.zip` alongside the source folders on the + share (manifests, as always, still live in the `Games\dosbox\` catalog regardless). + + A third variant found in the same comparison, `Games\duke3d_w32_bin.zip`, turned out to be + a **native Windows binary** (`duke3d_w32.exe`, needs `mfc70.dll`/`msvcr70.dll`) rather than + a DOS game — DOSBox can't run it; would need Wine, a real new dependency. Skipped per + explicit direction rather than expanding scope. + + Verified end-to-end with screenshots (`xwd`/`imagemagick`, installed temporarily for + testing only, not part of the image) — both games genuinely launch and render actual + gameplay (HUD, level geometry, taking hits), not just a menu. **Audio did not play for + either** despite `pactl` showing dosbox as a normal, uncorked sink-input — tracked down to + their carried-over `duke3d.cfg` (deleting it entirely breaks the game outright, forcing + `SETUP.EXE`, so it's required; likely has a stale/mismatched sound-hardware selection from + whatever machine last ran `SETUP.EXE` for real, rather than DOSBox's emulated SB16). Not a + bug in the audio pipeline itself — already proven working end-to-end for other games in the + sound TODO item above. Left as a known gap for these two specifically; fixing it would mean + either reverse-engineering `duke3d.cfg`'s binary format to patch the stored IRQ/DMA, or + finding a way to script `SETUP.EXE`'s interactive hardware wizard.