Exporting
A cart exists as bytes before it exists as anything else. Everything below — PNG file, play link, embed, standalone HTML — is a different container for the same cart, and the machine verifies them all the same way.
The cart PNG
export png saves a PNG containing the cart data in the low bits of its pixels: 160×205 for O8, 512×512 for O16, and 1024×1024 for O32. It is a real PNG — any image viewer opens it, email carries it, and dropping it into any omibit editor (or the player) loads and runs it.
Handle it like a cartridge, not like a picture:
- The cart file is canonical. Keep the PNG; it is the artifact.
- Do not re-encode it through an image editor — saving it as JPEG or
re-exporting from Photoshop mangles the data bits. Copy the file, never the pixels.
- The editor's autosave is a convenience, not a backup. Export a PNG at
every milestone.
Local project recovery
The projects library keeps each draft and its latest 20 saved revisions in this browser. If two tabs edit the same revision, the later conflicting save becomes a separate “recovered copy”; both projects remain available. Reopening an old revision also preserves newer work this way. Failed history writes leave an unsaved warning. Export a PNG before clearing browser data or moving to another device.
Share links
share uploads the cart bytes to the console's cart cache and returns a cart page of the form /cart/<hash> on the app origin — the game playable inline, the remix tree, comments, and the cart's verified replay board on one public page. The hash addresses the bytes: same cart, same hash, always — it is the state-hash machinery pointing at the whole cart. Anyone with the link plays the cart in the browser; no account, no install. The lobby lists everything in the cache, including the seed carts.
The site is a cache, not the source of truth. If it ever goes away, your PNGs still run — in the editor, in exported HTML, in the CLI. This is deliberate: links and files are two representations of the same bytes, and the file is the one you own.
Embeds
Any shared cart embeds with the player route: /embed?cart=<hash> on the app origin, an iframe-sized player with on-screen touch controls for phones. The embed carries a link back out to the full player, so an embedded cart is always one click from playable-in-editor.
To embed one of your own: share from the editor once, take the hash from the play URL, and point the iframe at the embed route with the same cart parameter.
Standalone HTML
export html bundles one cart with the entire player — core, font, input handling — into a single HTML file; its size depends on the tier and cartridge. It runs from file:// on a machine with no network: double-click and play. The export is self-contained; nothing is fetched.
Extended input and supported PCM samples travel with the cart and runtime. An offline file supports local play; internet invite rooms require the hosted relay and are not bundled into the HTML.
Use it for:
- A playable file you can hand someone with no infrastructure at all.
- Itch.io and game-jam uploads where a zip with one HTML file is the
expected shape.
- Archival: one file that is both the cart and the machine that runs
it. The file bundles its runtime; compatibility with future browsers still depends on those browsers continuing to support its web APIs.
Trust, but verify
Every container above holds the same bytes, so every container agrees with the machine. If you want proof for a specific export:
- The player shows a running state hash. Let a cart sit on its title
screen for a fixed number of frames and note the hash.
- From the repo, the CLI reproduces it:
omibit hash cart.png --frames 600 prints the first and last hash of the frame sequence. Same bytes in, same hash out — file, link, embed, HTML export, command line, all of them.
That is the whole verification story of the console, in miniature: same cart, same inputs, same hash, everywhere.
Named publication and retries
Public names are immutable claims. Publishing the same cart under its existing name is an idempotent retry; a different cart needs a different name. A name collision or full name index can leave the cart successfully published by hash. The share dialog retains that usable link and explains why the name was not assigned. Display names are not verified authorship or an account identity.
Editable source archives
Use export source to save a lossless .o8proj project, then import source to reopen it. The archive retains module boundaries, named assets, original import files/settings, authoring records and library locks. PNG/HTML exports contain the executable cartridge; they cannot recover original OBJ/WAV files or the project's module boundaries. Keep both a source archive and a playable export when sharing work with another creator.
Source modules use leading directives such as --@import move from "physics" and --@export move. Only reachable modules are bundled. The generated build is a read-only view; edit the selected source module instead. Invalid source can be saved and archived, while playable exports require a successful build. The editor reports code/bank limits and source-mapped errors. During an import it keeps the previous draft before replacing it; exports and edits wait for that operation to finish. A failed save leaves the old draft available.