Dated source reference. Current release status: handoff state. Full original relative paths are in the developer archive.

Native Quick Game startup and managed loading — development39

Current extension: Match controls51 completes the three planned additions: game-clock rotation intent with native entry observations, original native timeout calls and connected-input/team assignment.510 Windows API tests/84 schemas and focused live52w/52za/52x pass; multi-controller physical input remains unverified because no gamepads are available. This closes the planned match-control implementation, with that hardware verification outstanding. Presentation, broad modding/rule semantics and public packaging remain separate. The earlier evidence/version paragraphs below remain their recorded checkpoints; consult the new ledger for current implementation and exact limits.

This milestone ledger preserves development39/ABI17 native startup and loading evidence. Current private API46/ABI21 expansion, accepted/pending scenarios and limitations are in LAUNCH-EXPANSION and MATCH-REQUESTS. Older current-at-capture statements below are historical.

October17,2026. API0.2.0.dev39/HTTPv1, snapshotABI17/eventABI4, collegeprofile4/courtdefinition3. This extends roster loading and direct Start. It is private Windows development; public preview2 remains36/ABI14 and stable35 is preserved.

User experience

Native patches skip the opening-sequence/input wait, retain required asset/profile/controller initialization, and select Quick Game as the initialization destination. The original executable file stays unchanged. There is no generated title/menu input, external focus helper, or sequence of menu-navigation commands in the product startup path.

Normal startup defaults to Quick Game. To retain legacy manual startup, create openhoops/startup.ini beside the working EXE while it is closed:

[Startup]
QuickGame=0

Managed app launches explicitly enable native startup and prepare at Home under the loading cover, before creating team-preview UI. Use a separate working game copy when developing; current source is not silently installed into stable35. Manual opt-out is implemented but has not received a live legacy-route acceptance run.

Third-party integration

Run the broker in the signed-in Windows desktop session, with the matching complete ABI17 hook beside the supported EXE and the x64 _atomic.dll beside the Python package:

python -m openhoops_api --launch-game "C:\Games\OpenHoops\nba2k14.exe" --state "C:\OpenHoopsState"

The broker checks the EXE hash and the adapter's exported managed-startup version before launching. It passes startup configuration only to its child. Session0/SSH service startup is rejected; the application needs a process in the signed-in desktop. A broker setup/bind failure terminates its newly owned child. Normal broker exit leaves the game open; the external app owns the session lifecycle.

Wait for /v1/launch health ready, then use the same public launch SDK: admit/upload a hash-bound ROS, load it from inactive Home, apply participants/uniforms/arena/playbooks and Game Options, and issue match.start. All lease, run, catalog, revision, roster identity and durable-receipt requirements remain. The active Quick picker refuses API roster replacement; leave it for Home or start a managed launch. The cover remains through preparation and original loading; only a match requested by accepted native Start can reveal it. An attract/demo match is not a reveal condition.

bootstrap.mode is native_managed; acknowledgements is0. Startup observation contains four booleans: available declares the installed capability, managed identifies this launch mode, loading_presented records a successful loading Present, and match_revealed identifies the requested-match handoff. Manual picker reveal is not labeled a match. These observations are separate from match finality, legal ball state and command receipts.

App-customizable loading screen

Omit --loading-screen for neutral defaults. Otherwise pass a local UTF8 JSON file:

python -m openhoops_api --launch-game "C:\Games\OpenHoops\nba2k14.exe" --state "C:\OpenHoopsState" --loading-screen "C:\Dynasty\loading-screen.json"

Start with the default configuration. Version1 accepts title, subtitle, background_color, text_color, muted_color, accent_color, optional logo_path and background_path. Colors use #RRGGBB; text is one line, at most80/160 UTF16 units. Image paths must be absolute existing local PNG/JPEG/BMP files, each at most16MiB and8192×4320 decoded pixels. The broker freezes content-addressed private copies before creating the game. The background fills the view with cropping and a dark scrim; the logo preserves its proportions. The activity indicator is indeterminate, not a fabricated percentage. Caption/icon also use the app branding.

The contract is LoadingScreenConfiguration. It configures startup visuals; replacing in-game scoreboards, native team-picker art and presentation remains separate work. The managed cover currently reveals at original pregame phase4, retaining arena/lineup presentation. Pre-tip external-ID binding still begins later at phase10; whole-match event completeness is not claimed.

Implementation and evidence

The private adapter changes the original asset-drain mode operand and final initialization destination, then completes the title handoff after native profile initialization returns. That ordering matters: profile UI can reset title state on first entry. GUI transitions remain on the original update thread. D3D9 Present draws the loading cover and observes the normal seqlock publication; it never invokes GUI transitions. Separate startup flags prevent render-thread publication from becoming a second snapshot writer. Original runtime byte guards reject unexpected code.

Exact final non-probe DLL SHA256: c14d0579869fe7d50ffbaad9f3c608b5407380299e28795a830127a3eadc274f, compiled on Dell with MSVC19.51 /W4 /WX from46z. Source46z manifest, archive SHA256 3542ba7b6c6c507c6e19340e097c2c6a3e51a30f4d466171692551347996a254, identifies134 inputs. Frozen implementation archives retain their original docs; later documentation edits are separate.

• Earlier normal EXE46q reached native Quick Game in about10seconds without input, remained inactive for over a minute, and did not enter an attract match. Rendered picker, native observation.
• Earlier managed stock46s uses the public broker/SDK, neutral loading, exact roster SHA, all13 settings and native Start. All ten expected starters, zero errors, half180/OT60 and managed reveal pass; acknowledgements0. Workflow, loading, requested arena presentation. The32.4seconds measures client-ready request through match reveal, not total cold process startup.
• Final manual46zb uses the exact46z DLL, reaches native Quick with no simulation active, and accepts a guarded research-only bracket key after independent startup acceptance: Miami changes to Utah. Picker, after input, observation. That later input tests the picker; it is not part of product startup.
• Final branded46za uses the exact46z broker/DLL,905teams/13665players/3779uniforms, final rows903/904, uniforms3771/3776, arena18/books18/23 and all13 settings. All ten starters, roster SHA, half180/OT60, zero errors and requested-match reveal pass; acknowledgements0. Full workflow, app loading, native lineup presentation. The14.1seconds is client-request through reveal, not a cold-start benchmark.
• Final neutral46zc repeats the stock workflow on the exact46z broker/DLL from covered Home:105teams/1665players/579uniforms, all13 settings, ten expected starters, correct loaded SHA, half180/OT60, zero errors, requested reveal and acknowledgements0. Workflow, neutral loading, native lineup transition.
• 355 Windows API tests pass on exact46z imports, including ABI prefix, branding validation/freezing, owned-child bind-failure cleanup and picker replacement refusal. 41 schemas validate actual15-command bodies, live launch/roster/preparation/snapshot/receipts, custom branding and unchanged historical results. ABI17 is67624bytes, appending16bytes to ABI16's67608-byte prefix.

This is Windows11 windowed acceptance on the Dell. Fullscreen, device-reset/resolution transitions, first-run profiles on other PCs and all image encodings remain unverified. Existing ultrawide, college, native roster-capacity and result evidence retain their earlier scope; no new full-game/rare-rule certification is implied. Failed research attempts and watchdog stops remain preserved, separate from acceptance. Original corpus,95 reference saves, historical packages and independent artwork/download hosting must remain unchanged.

Earlier46v/46w demonstrated app BMP background/logo/title/colors, then failed after expanded roster decoding while Quick UI was active. A bounded debugger observed a null-object native read at CBC651. The context-specific fix keeps managed roster replacement at covered Home and rejects picker-context replacement in both broker and native adapter. This identifies the unsafe context without claiming a complete reconstruction of the UI ownership failure. Earlier discarded one-shot title confirmation ran before profile initialization reset it; the accepted post-initialization callback fixes that ordering. A failed research input check on46q sent no keys because the historical helper expected the old window caption; it is not startup-input evidence.

Acceptance46zd ties all final runs to the46z source/DLL. Preservation46zd,14:12:03UTC, verifies original EXE/stable35/all95 reference saves, restores all95 original files in the isolated test copy after archiving its last state, closes game/broker/debugger/API listeners, removes19 completed owned tasks and preserves both hosts and all three published ZIP hashes. The accepted DLL remains only in the isolated game; its restored original Config is not a new fullscreen acceptance. No test process is left running.