Crash BASIC 1.54.0 Release Notes

written by Crash-tan

YOUR MACHINE NOW HAS A NAME

Open the CrashPlayer launcher and there is something new in the bottom-left corner:

Device CBD-5GKVQA-PPGHAD-WM8SGF-MRXF29

That is this computer's Device ID. Click it to copy.

It is not an account, and it is not tied to one. It is worked out from the identifier your operating system already keeps for "this machine" — the Hardware UUID on a Mac, the Machine GUID on Windows, the machine-id on Linux — put through a one-way hash so what you see is a meaningless-looking token rather than anything about your hardware. The same computer always produces the same ID. A different computer never does.

Nothing on your machine is read or sent anywhere. The ID is computed on the spot, every time, and displayed. There is no setting for it and nothing to configure, which is the point: an ID you could type in would be an ID anybody could type in.

WHAT IT IS FOR

Games shared as a plain folder or an unstamped cart carry no license, so CrashPlayer shows the three-second unlicensed splash before them. That is the deal for freely-shared work and it is not changing.

What is being built is a way to buy that splash off on the machines you own — a small one-time purchase, for players rather than developers, that applies only to unsealed content. Games that ship sealed are untouched by it: their splash is their license's business and a device key cannot reach them. The Device ID is how a key gets bound to your computer, which is also why a key posted publicly does nothing for anyone who downloads it.

You cannot buy one yet. The store side does not exist. This release only puts the machinery in the player, and shows you the ID it will need. If you were hoping to click something today, there is nothing to click.

Two command-line flags come with it, for anyone who works that way:

crashplayer --device-id                      show this machine's ID and key status
crashplayer --install-device-key <file>      install a key issued for this machine

Installing checks the key against this machine before it goes anywhere, so a key issued for a different computer is refused on the spot with an explanation, rather than sitting on disk quietly failing every time you launch.

THREE COLLISION FIXES

Sprites that use ORIGIN, and behaviours that try to react to a hit, were quietly wrong. All three of these turned up from one small program: a block in a walled room that was supposed to bounce.

A sprite's ORIGIN no longer drags its collision box around. ORIGIN moves the anchor point within a sprite — ORIGIN(.5, 1) anchors it bottom-centre so you can position a character by the ground under its feet. The renderer honoured that; collision did not. It kept treating the anchor as the top-left corner, so the hitbox sat away from the sprite by exactly the origin offset. With ORIGIN(.5, 1) on a 32x32 block, that is 16 pixels right and 32 pixels down: walk left into a wall and half the block sank into it before anything stopped. Collision now applies the same shift the renderer does, so the box is where the pixels are. BBOX still measures from the sprite's drawn corner, so the two compose the way you would expect. Solid child sprites were off in the same way and are fixed with them.

If you have been nudging positions to make hitboxes line up, take the nudges out.

AFTERCOLLISION now fires after resolution on a solid hit. It was only firing when a sprite stopped touching what it hit. That reads fine until you notice that BVELOCITY re-applies every tick — a sprite walking into a wall keeps pressing into it forever and never separates, so on a solid contact AFTERCOLLISION never ran at all. The obvious handler, the one that flips direction when you hit something, was dead code.

A tick goes: contact, then resolution, then the next tick. ONCOLLISION runs on contact, still carrying the velocity you struck at; AFTERCOLLISION now runs between resolution and the next tick, once the engine has stopped or reflected you. A solid contact always resolves, so both land on the tick of the hit and neither waits for you to move away.

Ghost contacts are unchanged. A ghost has no resolution to follow, so its collision stays in effect for as long as the two overlap — you can wander around inside an otherwise-solid block for as long as you like — and its AFTERCOLLISION still arrives on the tick the overlap ends. Calling GHOST from inside ONCOLLISION still switches a contact to that behaviour, and phase-through works exactly as before.

Both are edge-triggered, as they always were: once per contact, never once per tick.

Re-issuing a running behaviour with new parameters takes effect. SET SPRITE 0 BEHAVIOR "Move", @vx=1 did nothing at all if "Move" was already active. It returned success and kept the old parameters, so a sprite could not be turned around by re-setting its own behaviour — the natural way to write a bounce, and the reason the block in that test program refused to come back.

Re-issuing with the same parameters is still a no-op, deliberately: a DO loop that re-asserts a behaviour every frame must not restart BMOVE timing or re-roll VARIANCE on every pass. Only a genuine parameter change rebuilds.

FOR DEVELOPERS: EVERYTHING ELSE IS UNCHANGED

No BASIC keyword, statement or function changed its syntax in this release. No sound or music behaviour changed. Apart from the three collision fixes above, a game that ran on 1.53.0 runs identically here.

If you distribute a sealed cart, nothing about your splash changes now or later — that was the first thing designed and the last thing that will move.

If you hold an Indie or Studio license, a device key will come with it when the store exists. You will not be buying the same thing twice.

UNDER THE HOOD

Some of this is only visible if you go looking, but it is worth writing down.

The splash decision used to be made in six places. Five of them hand-rolled the "no license stamp" case rather than asking the shared code — which happened to be the most common case there is, since a plain folder cannot carry a stamp. They now all ask the same question in the same place, so the desktop, iOS and Android players cannot drift apart on what a license means.

The player also says why it skipped a splash when it does, instead of attributing every skip to a Studio license. If you have ever wondered where your splash went, the answer is now in the log.