Crash BASIC 1.50.1 Release Notes

written by Crash-tan

VIDEO THAT REMEMBERS YOU TAPPED

First, the honest framing: this is a small nicety, not a headline. The native iOS CrashPlayer app has been around for a good while, and it's how people actually play Crash BASIC games on an iPhone or iPad — video and everything else has always just worked there. What this fixes is the browser fallback on iOS, a corner most players never touch. It's been quietly broken for a while, it's finally fixed, and it's nice to have the web player tell the same story as the app. That's all — but "finally" is a good word.

So: play one of your games in an iPhone or iPad browser (not the app) and the first PLAYVIDEO would just... refuse. No picture, no sound, and a grumble in the console about the request "not being allowed in the current context." Muted video was fine. The moment it had sound, iOS slammed the door.

Here's what iOS was actually upset about. On iPhone and iPad, a video with sound is only allowed to start playing as the direct result of you touching the screen. Not a moment later — right then, as part of the tap. And Crash BASIC wasn't playing by that rule. Every time your game reached a PLAYVIDEO, the web player made a brand-new video element on the spot and told it to play. But PLAYVIDEO happens deep inside your running game — seconds, sometimes minutes, after the tap that launched it. iOS looked at this fresh element asking to make noise with no finger behind it, and said no.

The fix

Now the web player gets its permission slip signed the instant you tap to start a game. At that first touch it quietly wakes up a single video element — plays and pauses a heartbeat of silence to bless it while your finger is still on the glass — and keeps that same element around for the whole session. Every PLAYVIDEO after that reuses the blessed one instead of minting a stranger. iOS remembers you tapped, so your video plays, with sound, right where you asked for it.

Nothing to change in your game. PLAYVIDEO, STOPVIDEO, WAITVIDEO, and the rest read and run exactly as they always have. And to say it once more: this only ever touched the web player on iOS — the native iPhone and iPad app was never affected, and other browsers never cared. A small corner, finally tidied.

CUES THAT COME BACK AROUND

1.50.0 taught PLAYMP3 to loop just a slice of a song. This release fixes the thing that was supposed to loop right alongside it: your event cues.

If you sync game events to music with EVENTSON, the docs have always promised that a cue point fires again on every trip through the loop — a downbeat at 2.0 that fires two seconds in, every time the loop comes back around. In the web player it did. On native, it fired once and then went quiet forever. The cue list drained the first time through and never refilled, so a looping battle theme lit up your effects on the opening bar and then left you in silence for the rest of the fight.

The fix

Native now re-arms its cues every time the loop wraps — for whole-clip loops and SECTION loops alike. A cue at 0.0 fires at the top of every loop; a cue partway in fires each time the playhead passes it; and when you're not looping, cues still fire exactly once, same as before. Native and the web player finally tell the same story, and both match what the docs said all along.

Nothing to change in your code. If your looping music felt strangely quiet after the first pass on a device, it won't anymore.

THE DEBUGGER STOPS HIDING YOUR ARRAYS

Stop on a breakpoint, open a variable, and if it was an array the debugger just showed you a placeholder — a little "it's an array" shrug where the actual values should have been. The one moment you most wanted to see what was in the thing, it showed you a label instead of the contents.

Now it shows you the contents. Inspect an array while paused and you get its actual elements, the way every other variable already worked. Nothing to change — just open it and look.