# Crash BASIC 1.36.0 Release Notes

*~written by Crash-tan~*

## THE RUN-IT-FOR-REAL RELEASE

This one's for everyone building in the CrashBasic IDE. Until now, hitting Run
gave you the browser sandbox — fast, convenient, but *not* the engine your
players actually use. As of 1.36.0 you can **run and debug your game in the real
native CrashPlayer, straight from the IDE.** Same engine, same window, same
behavior your players get — now with the debugger wired right back to your editor.

The **Run** and **Debug** buttons are now **split buttons** — the main button
does exactly what it always did (run/debug in the browser, instant), and the
little **▾** beside each opens a **Native** option:

```
   [ ▶ Run │▾ ]      [ 🐞 Debug │▾ ]      ⏹ Stop
            └ Run Native       └ Debug Native      → the real CrashPlayer
```

Click **Run** or **Debug** and nothing changes — browser/WASM, same as always.
Click the **▾** and pick **Run Native** or **Debug Native**, and the IDE builds
your game, hands it to a real CrashPlayer on your machine, and runs it there. For
**Debug Native**, breakpoints, stepping, the call stack, and variable inspection
all flow back into the IDE — driving the real engine instead of the sandbox.

---

## Push, don't host

The old way to get a game into a native player meant exporting a file, hosting
it somewhere, and pointing the player at a URL. Forget all that.

When you pick **Run Native** (or **Debug Native**), the IDE **builds and stamps
your cart in the browser and pushes it straight into a running CrashPlayer** over
a tiny local connection. No files to juggle, no server to stand up. And if
CrashPlayer isn't open yet, the IDE launches it for you and waits for it to come
up — you just click the option.

The game renders in CrashPlayer's own native window. The IDE becomes your
control surface.

---

## Real breakpoints, in the real engine

Debugging used to mean debugging the WASM build. Now you can debug the **native**
build — the one with the real graphics backend, real timing, real everything:

- **Breakpoints** you set in the gutter stop the native game cold.
- **Step over / into / out**, the **call stack**, and **variable inspection** all
  work against the live native process, in the same debug panel.
- It's the same debug protocol the in-browser debugger speaks, just driving a
  real process over the wire — so the experience is identical, the engine is real.

### Debug doesn't stop on entry anymore

A correctness fix that matters: **Debug mode no longer pauses on the first line**
(and never breaks inside the splash screen). It runs and stops *only* at the
breakpoints you set — and if you set none, it just runs, with the debugger
attached for inspection. That's how a debugger should behave.

### Stop means stop

The **Stop** button now genuinely ends the native session: the program halts, the
game window closes, and everything tears down cleanly — whether the program was
running, looping, or paused at a breakpoint.

---

## Click-to-launch: `crashcart://` and `crashplayer://`

CrashPlayer learned two new browser-clickable URL schemes, joining the existing
`crashnet://` (multiplayer):

- **`crashcart://host/path/game.crashcart`** — a clickable link that downloads a
  hosted cart and runs it in CrashPlayer. Tack on **`?debug=1`** to launch it
  straight into a debug session.
- **`crashplayer://`** — bootstraps CrashPlayer as the IDE's run/debug target
  (this is what the IDE uses behind the scenes to bring the player up for you).

These are the plumbing that makes "click a link, play the game" and "hit Run, see
it in CrashPlayer" feel seamless.

---

## Unzip-and-it-just-works

Installers are great, but nobody's required to use one — sometimes you just
unzip CrashPlayer into a folder and double-click it. So now, **on every launch,
CrashPlayer registers its file associations and URL schemes to wherever the
binary actually lives** — on **macOS, Windows, and Linux** alike.

Drop a fresh CrashPlayer into any folder and, without running a single installer,
double-clicking a `.crashcart` opens it and `crashcart://` / `crashplayer://`
links route to it. It self-heals to the copy you actually ran last, no admin
rights required.

---

## The splash eats its own dog food

Small but satisfying: the built-in CrashPlayer splash screen now renders through
**`MEMORYBUFFER`** (the bake-it-once trick from 1.35.0). Its artwork is rasterized
into a texture a single time and then just stamped down, instead of re-drawing
primitives every frame. Faster, lighter on the renderer, and a nice proof that
the feature earns its keep in production code — not just demos.

---

## Compatibility notes

- **Purely additive — no language changes.** There are no new (or changed) Crash
  BASIC keywords, functions, or behaviors in 1.36.0. Every program you've written
  runs exactly as before. This release is all about the *workflow* around your
  game, not the language inside it.
- **Browser run is unchanged and still the default.** The plain **Run** and
  **Debug** buttons behave exactly as before; native is opt-in behind the **▾**.
  If you never touch it, nothing changes for you.
- **The bridge is local and loopback-only.** The IDE talks to CrashPlayer over a
  local connection on your own machine, gated to the IDE's origin — nothing is
  exposed to the network.
- **No-lingering processes.** When a debug game closes, the local bridge it used
  exits too — no stray windows or background processes left behind.

---

*Stop testing the shadow. Run the real thing.*

*— Crash-tan*
