common/scripts/ was replaced by the docker-common repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NiNnj78HGx1KWyCCo39HSz
4.3 KiB
TODO
-
~
Reduce image size ofDone in two steps:jayfield/dosbox-novnc(currently2.3GB).- Merged the game download/extract steps and the unzip/smbclient install into a single layer (so the downloaded zips and the packages only needed to extract them no longer persist in the final image). 2.31GB -> 1.6GB.
- Stopped baking the games into the image at all (927MB of that was just t7g's two CD
ISOs).
run.shmounts a named volume (dosbox-games) so installed games persist across--rmrestarts. 1.6GB -> ~690MB. Container now needs network access tovlda-01at runtime (not just build time) to install games. - Dropped the auto-download at container startup entirely.
scripts/setup_server.pyis a small stdlib-only HTTP server (started alongside Xvnc/fluxbox/websockify) that serves an HTML page on${SETUP_PORT}(70${DISPLAY_NUM}, published as7099byrun.sh) listing every*.zipon the SMB share with an Installed/Install status per game; the user clicks "Install" to fetch+extract a specific game into${GAMES_HOME}on demand.
-
Manifest-driven games + Start/Stop/Uninstall (test balloon,
stuntcaronly): games are no longer discovered from raw*.zipfiles on the share.setup_server.pynow lists*.jsonmanifests instead (one per game, e.g.Games\dosbox\stuntcar.json), each declaringname/title/zip/start_cmd. The web page grew Start/Stop/Uninstall buttons alongside Install, driven entirely by that manifest — nothing about a game's identity or how to run it is hardcoded in the image anymore. Onlystuntcar.jsonexists on the share so far (as a deliberate pilot);t7ghas no manifest yet and will not show up in the setup page until one is added (t7g.jsonwith astart_cmdfor itsdosbox-0.74-3.conf).game.sh/scripts/start_game.sh(the olddocker exec-based launch path, with its hardcodedDOSBOX_VERSION/run.batconvention) were intentionally left untouched for this pilot and now overlap with the new Start button — worth reconciling (or removing) once the manifest approach is rolled out to all games. -
Create manifests for SCUMM engine games (Monkey Island, Day of the Tentacle, Indiana Jones, etc.). Note these are usually best run via ScummVM rather than raw DOSBox —
scummvmisn't installed in the image yet, so this may need a Dockerfile change (add thescummvmpackage) alongside the manifests themselves, and each manifest'sstart_cmdwould invokescummvmwith the right game-id instead ofdosbox run.bat -conf .... -
Get game sound actually audible during play.
--device /dev/sndis passed through andalsa-utilsis installed, so DOSBox can write to an ALSA device inside the container, but VNC/noVNC only ever streams video, not audio — nothing currently carries that sound out to the browser.Target latency is a few tens of ms, not seconds — that rules out the "obvious" approach of a PulseAudio null sink piped through
ffmpeginto a compressed (mp3/ogg) HTTP/Icecast-style stream consumed by an<audio>tag: codec frame buffering plus the<audio>element's own jitter buffer realistically puts that in the 1-3s range, no matter how it's tuned.Concrete approach instead: PulseAudio null sink → capture raw/lightly-buffered PCM (small frames, e.g.
parecwith a short--latency) → push those frames to the browser over a plain WebSocket (new endpoint alongsidesetup_server.py, or a small dedicated process) → browser side, feed them straight into the Web Audio API via anAudioWorkletNode(not<audio>, notScriptProcessorNode— that's deprecated and has worse latency) for near-real-time scheduled playback. No container/codec framing in the path at all.Build this to be reusable across the other noVNC-family projects (
docker-xserver-novnc,docker-sdr-novnc), not dosbox-specific — it's a "browser audio + noVNC" concern, nothing about it is really about DOSBox. Follow thedocker-common/scripts/signals.shprecedent (see thedocker-commonrepo): keep the generic PulseAudio-sink/WebSocket/AudioWorklet piece project-agnostic there, then copy it (not symlink) into each project's ownscripts/the same way signal handling is shared, so a fix in one place gets propagated by hand to the others.