OPENHOOPS / 2K14Final team archive · November 9, 2026Reference libraryChecksums

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

Packet preparation publication, version 1

The opt-in packet adapter publishes copied UI submissions before handing the native frame packet to the renderer. This lets a producer prepare resources and text earlier. Packet.1 is a read-only development contract. It does not grant permission to hide native output, prove that glyphs are visible, or report sequence completion. The production packet capability mask remains zero.

The mapping is Local\OpenHoops.Presentation.Packet.1.<channel-token>. It belongs to the exact game PID and process creation time reported by the existing pixel channel. Consumers open it with FILE_MAP_READ; they do not acquire the pixel producer's mutex. See framework/packet_publication.py and native/presentation/packet-publication.hpp for independently checked layouts.

The 64-byte header identifies version, process, record size and 16 bounded slots. Each 160,848-byte record has its own aligned 64-bit seqlock. A slot contains the latest publication for that slot; consumers must detect missed incarnations rather than assume this is a lossless event journal. Records may remain after retirement, and a readable record does not prove an execution is still active.

Identity consists of ledger domain, slot, incarnation, run nonce, epoch and device generation. Domain/incarnation/serial values are opaque identities, not native addresses. Resource identity contains a registry token and the full verified asset SHA256. No packet, builder, controller, material or texture address is exported. Reuse of a native address cannot reuse the opaque identity.

A record has at most 64 submissions and 256 total fields. Each submission keeps its original begin/seal timestamps, owner/root, serial, revision and refusal flags. Each field retains native node ID, optional portable key, complete bounded UTF-16 text and copied opacity/measurement style. Key zero is retained; unmapped visible text must not disappear into an apparently complete replacement. Overflow/incomplete capture is flagged and never exported as a truncated valid submission. A private ledger publication view stays under its writer gate until the record is copied, then release-publishes the packet.

Begin and seal observations/facts are separately sampled game-thread values. Their timestamps are never renewed. Equal observations do not prove that a cached native UI node used those values. Samples expose native_text_provenance=False; any later content/facts join needs its own exact submission binding and native-field checks. No current draw-time or 100 ms freshness rule is changed by this mapping. The reader's 250 ms publication-age limit only bounds preparation data, and does not authorize pixels that old.

PacketReader.read(run_id=..., epoch=..., generation=...) returns currently matching, coherent records ordered by opaque identity. available describes readable preparation data; complete additionally means its capture has no recorded refusal. Both still report ownership_eligible=False, actual_draw=False and native_sequence_authority=False. A package must not publish an omission claim merely because preparation data is available.

AU3 tests cover independent C++/Python binary decoding, unmapped and hidden text, sample age/identity, corruption, reuse, failed publication, two actual read-only Windows consumers and rejection after the owning process exits. The original root/interpreter and real-host adapter fixture also publish this mapping. Queue, asset-loader and driver fixture limits remain explicit. No native-game acceptance or stable distribution is implied.