Golden Balloon 1.0.1

Golden Balloon 1.0.1

Windows WebGPU presentation no longer blocks the cooperative game/audio thread
after each submitted frame. This restores the responsive startup audio and menu
animation behavior of 1.0.0. Production submits only newly authored images and
polls GPU completion without a synchronous runtime drain.

Released 2026-08-01.

Golden Balloon 1.0.1 is the first native patch release. It repairs the macOS
package, keeps experimental host-pacing choices separate from the proven
Original mode, and keeps WebGPU as the native default. No game data is included.

What changed

• The macOS app is self-contained again. The old package accidentally
  bundled Homebrew's sdl2-compat shim, which dynamically loaded an unbundled
  SDL3 from the build machine. The replacement uses SHA-pinned standalone SDL2
  2.32.10, embeds its license, targets arm64/macOS 13, and rejects Homebrew,
  SDL3, unresolved load paths, mismatched architectures, and newer hidden
  deployment targets.
• The “damaged and can't be opened” failure is fixed at the package
  boundary. Nested code is sealed before the outer app after every bundle
  mutation, and the finished DMG is checksum-verified, mounted read-only, and
  revalidated in place. The exact app inside the mounted, read-only DMG must
  then launch through LaunchServices, select WebGPU, present and capture four
  real surface frames, and load no Homebrew or SDL3 libraries.
• WebGPU is the native default. Dense opening-sequence captures found
  localized sky/terrain texture corruption in the OpenGL path that sparse
  sampling had missed. WebGPU does not show that corruption and is also the
  project's extensively tested browser backend. OpenGL remains available with
  MDKR_RENDERER=gl as a diagnostic path, not the default release path.
• Windows startup audio and menu timing are restored. A post-1.0.0 queue
  bound called wgpuDevicePoll(..., true) after every second native WebGPU
  submission, synchronously draining the native WebGPU queue on the same
  cooperative thread that advances gameplay and refills audio. Production now
  polls completion without blocking and reserves the explicit queue bound for
  browser/internal replay stress. The final portable candidate passed a
  real-hardware Windows retest from launcher through intro, character select,
  gameplay, audio, and relaunch.
• Numeric and Uncapped frame limits no longer crash the native app. The
  adopted OpenGL context now initializes its function loader before the pacing
  code can use sync/fence entry points. Real launcher tests exercise both
  WebGPU and explicit OpenGL with the 240 and Uncapped policies. For 1.0.1,
  every non-Original choice is marked Experimental — Under Construction in
  the launcher and affects host pacing/input/event-pump opportunities, not
  unique visual FPS. Any benefit may be negligible, while higher settings can
  use more CPU.
• Unsafe motion smoothing is disabled for this patch. Release-candidate
  play-testing found that delayed display-list replay could run after the game
  had begun rewriting mutable viewport, matrix, vertex, texture, and display-
  list dependencies for the following task. The safe 1.0.1 policy submits only
  new authored images. The primary US 1.1 build remains at its authored roughly
  30 unique visual FPS, with no duplicate swaps. This removes the off-center
  UI, missing vehicle parts, fractured geometry, and related high-rate artifacts
  from the release path.
• Gameplay compatibility was re-checked. Automated Original-mode replay
  remains byte-exact with the pre-patch baseline. A direct two-player gate now
  proves exact P1/P2 controller-to-racer binding, button edges, stick input,
  and independent motion across GL/WebGPU at 60/120 Hz; the determinism and
  render-purity controls remain green.
  Numeric and Uncapped choices change host pacing only; they do not accelerate
  the simulation or increase the authored visual frame rate.
• Magic codes load and validate correctly. The decrypted big-endian table
  is normalized and fully bounds-checked before publication, fixing the
  reported 8/blank enabled-code rows and universal “code was incorrect”
  result without allowing a partial table through.
• The launcher and in-game overlay are cleaner and safer to use. Navigation,
  dropped-ROM intake, boot configuration, overlay state, confirmation flows,
  and panel rendering now have small named owners with typed state instead of
  a monolithic draw path. Invalid ROM replacements and failed preference writes
  leave the last-known-good choice active; a failed setting retains the value
  you entered and can be saved through the visible Retry button after write
  access is restored, without restarting the app. Escape and controller B now
  follow the same popup → confirmation → Settings → overlay back stack.
• The native launcher now adapts to its window and display. Its supported
  minimum is 640×480, where the side rail becomes compact top navigation and
  wide controls/actions stack instead of clipping. A persisted 0.75×–2.00× UI
  scale changes text, controls, and spacing together; moving between standard
  and HiDPI displays rebuilds the font atlas before the next frame.
• Native accessibility scope is stated explicitly. The launcher supports
  keyboard and gamepad navigation, visible focus, scalable high-contrast UI,
  and restrained motion. This patch does not claim a native VoiceOver,
  UI-Automation, or other screen-reader semantic tree.
• Return to Launcher shuts down cleanly before relaunching. The engine,
  borrowed renderer objects, host, and diagnostic log reader unwind before the
  resolved executable replaces the process. A failed relaunch is visible and
  returns an error instead of hanging on an orphaned diagnostics pipe.
• The Linux portable release is GPU-gated and self-contained. Linux and
  Windows validation builds compile the requested version and assert the binary
  reports it before packaging. The public portable files are
  Golden-Balloon-1.0.1-linux-x86_64.AppImage and
  Golden-Balloon-1.0.1-linux-x86_64.tar.gz. Before upload, deterministic
  Xvfb + Mesa software-GPU lanes content-validate the real launcher through
  default WebGPU and explicit GL, then extract the tarball, launch its AppRun
  from an unrelated directory using bundled SDL2, and repeat both pixel gates.
  Those Linux files are published only if that complete workflow passes; a
  failed or unavailable lane produces no endorsed Linux binary.
  Windows builds, import-checks, packages, and launches from its extracted zip,
  but windows-latest cannot guarantee a qualifying GPU/API surface. The 1.0.1
  Windows zip therefore received a separate manual native WebGPU gameplay,
  controller, audio, save, and relaunch acceptance pass on Windows hardware;
  the automated startup checks are not presented as a rendered gameplay gate.
• Release checks fail closed more often. Merge commits and pushed ref tips
  receive public-surface scans; committed-then-deleted history is checked;
  privacy and browser-presentation tasks are pinned by the CI contract; and
  the macOS target, dependencies, runtime loads, version, commit, renderer, and
  bundled license are independently verified.

FPS behavior

The launcher identifies Original as Recommended / Proven and marks Match
Display, numeric choices, and Uncapped Experimental — Under Construction.
In 1.0.1 these settings only alter host pacing and input/event-pump
opportunities. They do not increase unique visual FPS, swap duplicate images,
or speed up the game's authored simulation. The primary US 1.1 build remains at
its authored roughly 30 unique visual FPS. Any benefit may be negligible, while
higher settings can use more CPU.

Motion smoothing and delayed display-list replay are fully disabled for this
patch. The replay experiment could not prove immutable ownership of every
viewport, matrix, vertex, texture, and nested display-list dependency through a
delayed walk. The faster historical one-field simulation remains a separate,
explicit compatibility option; it is not enabled by Frame Limit. Use Original
for the recommended release behavior.

macOS first launch

This patch intentionally skips Developer ID signing and Apple notarization.
The app is ad-hoc signed for code/resource integrity, but macOS may show the
ordinary unidentified-developer warning. After the first blocked launch, open
System Settings → Privacy & Security, scroll down, choose Open Anyway,
and confirm Open. Apple documents that current flow in
Open apps safely on your Mac. A “damaged”
warning is not expected and should be reported as a bug.

The release artifact is Apple silicon only, requires macOS 13 or later, and is
named Golden-Balloon-1.0.1-macos-arm64-unsigned.dmg. Its checksum and
provenance sidecars identify the exact source commit and record
macos_signing: ad-hoc-unsigned so it cannot be mistaken for the optional
Developer ID/notarized flavor. If that trusted flavor is published later, its
exact name is Golden-Balloon-1.0.1-macos-arm64-signed-notarized.dmg and its
provenance records macos_signing: developer-id-notarized.

Current limitations

The patch does not expand its claims beyond the tested WebGPU paths: the
complete campaign is not automated end to end, OpenGL remains diagnostic while
its opening-sequence visual-parity issue is open, macOS requires the manual
first-open approval above, and Linux has less physical-hardware coverage.
Windows build/package/startup checks are automated, while native GPU gameplay,
controller, audio, and save acceptance remains a manual gate that passed for
this candidate. On Windows, wgpu-native automatically selects a compatible API
and may use Vulkan or Direct3D 12; MDKR_RENDERER does not force either one.
Windows 1.0.1 also requires reasonably short, ASCII-only paths for the extracted
app and ROM. If the launcher cannot save an otherwise valid ROM choice, launch
GoldenBalloon.exe --rom C:\ASCII\game.z64 from Command Prompt and report it.
Explicit WebGPU API selection, richer diagnostics, wide-character filesystem
support, and a reviewed application manifest are deferred to 1.0.2.
Non-Original frame-limit
choices remain Experimental — Under Construction and may add CPU cost without a
noticeable benefit; use Original for the proven cadence. See
README — Current limitations and
ROADMAP.md for the exact deferred scope.

Two related projects

• Native desktop port: akratch/goldenballoon
• Browser build: akratch/golden-balloon

Both still require a legally owned US 1.1 or European 1.1 ROM. The ROM is read
locally and is never part of a release artifact.

Release validation

• Source/tag commit: aff75ca1b54dc76bf0238f0c6649f5470972ff2d.
• Windows manual acceptance: PASS on maintainer hardware through default-WebGPU launcher, intro/character-select timing, gameplay, controller, audio, save, exit, and relaunch. The final archive was reproduced from the same accepted runtime source after a standards-only native symbol rename and release-workflow hardening.
• Windows archive SHA-256: e3be4045045e003a78113713a92145287629112401f585f26e2288b283cb4aac.
• macOS DMG SHA-256: 4dab44e0abe761f0988f890cc14f0d9c1e6e9b6c2c61c11afdeafe06217c25be.
• Linux AppImage SHA-256: 82f6fcc3d91503ab5b2d3ab24014aeee5815575f37a79214a5cbfbc924e9a9c2.
• Linux tarball SHA-256: ad5c81e26169b92d1b8a8e60816be6a92e5501a083f69533e485e90cbb247144.
• All four platform assets have clean provenance sidecars binding them to the source/tag commit above.
• Use the exact-artifact release-candidate test guide for the final cold-start hardware spot check.