Space Rocks 3D!

Great, then I could add a cockpit overlay after all without needing to worry about exhausting RAM. I suspect there’s some performance cost for drawing it every frame, but that should be minimal when it’s handled by fast native code.

1 Like

Now I have to watch The Last Starfighter! What a great game and I think the cockpit will be a nice addition. It runs great on the Pygamer!

1 Like

Yes, the array will take 4 bytes per element. As you add elements to the array it grows, so it may be slightly bigger than required. There is currently no way to avoid that.

There may be a memory leak somewhere. I take it the profiling in the browser doesn’t show any new objects staying alive after each frame/level?

Yeah, TS unfortunately has only one number type, and it would be really difficult for us to change this.

The Fx module uses an abstract type and casting (which has no runtime cost) to keep this type-safe. You have to then say Fx.add(a,b) instead of a+b. You could do something similar, or just use the Fx module.

1 Like

this kida looks like star fox


Yeah, that’s what we all think

1 Like

Here’s another new build:


  • Added a cockpit dashboard overlay by popular request.
  • Asteroids now rotate!
  • Moved the laser heat gauge to the dashboard, it’s now an energy meter that drops as you fire.
  • Various updates to internals to save memory and fix renderer issues.

Please let me know in case you see any performance regressions, especially on hardware devices.

Would you be willing to check if it’s still crashing on Meowbit in this version? I’ve tried to reduce memory consumption.

There are some smallish reallocations after each level. I’m using an array with reusable triangle data (trapezoids) to reduce the per-frame garbage collector churn. That array grows a bit for each new level, but it only has ~150 elements and generally doesn’t need to reallocate during levels. I’ve switched the data representation for the underlying trapezoids from numbers to bytes in a buffer which reduced the data size from 48 bytes to 8 bytes.

The overall memory usage seems to be holding steady around 40kB, but I’m not sure if that’s representative of what it looks like in hardware.

Out of curiosity, is there a way to force a RAM limit, for example making a PyGamer pretend it only has 96 kB? That would make it easier to verify that games still work on low-memory devices.

That is very cool, I clearly need to read up on advanced TypeScript. I wasn’t aware that it’s possible to make no-overhead abstractions like this. Thank you again for the feedback!


Cool! I decided that I wanted to make my own cockpit, so here it is!



Wow, I love it! It works on my meowbit hardware too.

Are you planning on making an accelerometer-controls version? I see a hint of that at line 238 in your code. That could be cool!

@edubsky, it already has accelerometer controls - use the B button to cycle through the four control schemes. The first post has a description. I prefer “tilt roll/pitch” myself, and I think it’s easier to play with analog controls.

@GameGod, your cockpit looks great, though it unfortunately blocks the radar display. It should be possible to move that into a separate image instead of drawing it on the background, but I’m not sure how big the performance impact would be. Also, maybe try making half the pixels in the top panel transparent in a checkerboard pattern to get a partially see-through roof? The restricted peripheral vision makes the game a bit harder. Edit: Also, new waves don’t get any asteroids in your version, did you make other changes also?

Hey kwx,
That version works much better on MeowBit, I played til Level 7 then I was hit by a boulder for the third time and died. It crashed right in the moment when I was hit.
I checked if that was coincidence, but no! Even if I let 3 boulders hit me right in the beginning of level 1 I get error 021.
Performance was really good, a little lag at the beginning of level 6 and 7, but much better than the last version. Impressive :slight_smile:

1 Like

@GameGod, here’s a version using your awesome cockpit, slightly modified to add semitransparent panels and fixing the radar display:

I am getting occasional garbage collection pauses on this one, though I’m not sure if that’s caused by the extra radar layer. It may be less Meowbit-compatible as a result.

Interesting, maybe the “game over” screen needs more memory than it has left at that time? I added code in v4 to reset some cached data before triggering the game over, that might help if that’s the case.


Here’s one more update. Unfortunately the semitransparent panels caused a rather unpleasant flickering effect for the starfield background, so I switched to fully transparent windows. (@GameGod, sorry about the radical modifications, but I found the fully enclosed cockpit a bit too claustrophobic.)

Out of curiosity, is there an extension that supports a settings screen with persistent storage? It would be nice to give the user a choice of cockpits, control scheme, and difficulty settings, but it’s a bit clunky to implement that from scratch.


Same here!

Don’t be! This game is epic!


same here

It’s actually amazing how far this sim has gone

v5 still crashes on Meowbit when all lives are lost.
I will try to look into the code when I have some time, maybe if I add a little pause before the game over screen.
I remember, I had a crash too at the end of my game Pergamon arcade
I think there will be a makecode arcade compatible shield for micro:bit v2 announced in the blog.
This looks like a perfect fit for Space Rocks 3D. Navigating with the tilt and compass sensors :slight_smile:

Try this version which has some cleanup logic at game over, does that help?

Other changes:

  • Fix the sprite Z order so that explosion now happen outside the cockpit
  • Updated laser animation
  • Shortened the pause between waves
  • Some code cleanups and restructuring. For example there’s now a useCockpit variable you can set to false if you prefer the open-space experience.

This is insane…howwww lol.


Gameplay changes:

  • Press the B button for a speed boost. Use with care.
  • The playing area now wraps around, asteroids no longer bounce off invisible walls.
  • When starting a new wave, make sure the asteroids aren’t too close to the player.
  • Added a new accelerometer control scheme using tilt yaw/pitch and stick roll.

The game now starts at a settings screen that allows choosing the control scheme, cockpit on/off, and some graphics-related flags. You can also choose a starting wave for increased difficulty. The settings are stored persistently using the settings API, so they should remain set across restarts.

Behind the scenes, I restructured how it draws to the screen, cutting the memory consumption almost in half (from ~40kB to~ 25kB according to heap snapshots), and increasing performance a bit. Boring technical bits following, feel free to skip these :slight_smile:

I had been modifying scene.backgroundImage() since I thought that this corresponded to the screen buffer, but that’s actually a separate in-memory image which needs about 10kB, and also needs to be copied to the screen every frame as an additional internal step.

Now I’m using scene.createRenderable() instead, this is far more efficient since it actually does draw to the screen buffer directly. It’s also integrated into the scene Z hierarchy, making it easy to structure UI layers without needing separate images. See the Is it possible to write directly to screen (pixels) on the Arcade? thread for more information on this.

This also made it possible to simplify the starfield background code a lot, and to add screen shake effects to the radar screen for consistency.