MakeCode Kart

Sorry, my example had confused variable names. Replace “target” with “image” like this:

scene.createRenderable(zLayer, (image: Image, camera: scene.Camera) => {

(Or alternatively, keep that line the same and use “target” instead of “image” in the for loop.)

Thanks @kwx and @richard, I’ve made a VERY basic demo of just a squished image that runs ~100fps on a 6+ year old pc!

No rotation or scaling yet, that would be kind of hard.

1 Like

Quick follow up: I’ve made it render the same thing, but just for the screen instead of a specific image!

I made an extension for this:

Can this scene be destroyed or is it permanent? I’d like to be able to dynamically add and remove filters that I make. Thanks in advance for any help!

If I’m understanding it right, scene.createRenderable() adds new drawing code to the current scene, and the supplied function is called on every screen update. It’s up to you what you draw there. I don’t know offhand if there’s a function to remove a renderable, but you could simply add a if (!thisFilterActive) return at the top of the drawing function to just do nothing unless you want the filter or effect to be active.

Alternatively, I think you could use game.pushScene() and game.popScene() to switch out the scene entirely, and any renderables would be restricted to the currently active scene. More here: How set a button to Pause the game? - #4 by richard

@Kiwiphoenix364 are you using scene.createRenderable? If so, it returns an object you can destroy like so:

const myRenderable = scene.createRenderable(1, (target, camera) => {



Thanks so much @kwx and @richard, I’m still working on how to make it stop trying to run the processes on the filter once it is destroyed, and I might figure it out! I’m hoping to have a real time blur filter for the blur extension.

I made a demo that could work for this project and runs at a great framerate (~1400-2400fps)! The only things that need to be worked on is the black lines on screen, scaling it larger, having objects on top of the terrain, and rotating the picture relative to your character’s position (rather than the center of the image.

Looks closer and closer to looking like an snes game, kinda like recorded from a CRT TV screen

The black lines appear due to some pixels not getting drawn. To fix that, just change the loop to cover destination pixels (instead of source pixels), and move the map to calculate the source pixel (instead of the destination pixel).

Here’s what that looks like - it’s switching methods every 10 frames to confirm that the distortion is the same:

This approach may not be technically correct, but but if it looks good enough for the game it’s worth a try. For a more accurate approach, you’d need to look up how to do perspective corrected texture lookup, and that’s a bit more tricky.


I made some optimizations, as I thought the framerate was good, but forever loops are deceiving, and it only ran at 4fps (thanks for making that obvious with the on-game update block). I made many optimizations and got the framerate to 20fps! Here it is!

@KWX do you (or anyone else on the forum) know any more optimizations? I’m open to any suggestions, including using JS/TS (as long as the JS/TS can be turned into gray blocks so others can add characters). I’d like to get it to at least 30fps (like Super Mario Kart), but preferably 40/50 fps. Also, I’d like to implement more features like working controls and camera for a kart in the future.

1 Like

Here’s my attempt at perspective corrected texture mapping. It’s a bit of a hack, but seems to work reasonably well on the emulator. (It would need a conversion to fixed-point math for running on hardware.)


WOAH, that’s so cool! Is it okay if I use this as a base for a game (Mario Kart clone)? I’ll definitely credit you!

I just made a road like the ones in Out Run style games, all in code blocks. You just shift rows of pixels side to side, lots of maths involved but it’s not that complex tbh.


1 Like

Great! Learned many for your fast and clear code.
When I saw setPixal(), I thought, whould it be more faster if replace setPixel() with setRows().
So this is the test result (slight change based on yours). With my test, on my pc sim, about 80 fps (about 40fps before)

Have a review pls. Let me know if there’s any issue.


And I did another test, add below line, to show out which pixels in bg img read. (only the white sector zone).

            scene.backgroundImage().setPixel(u * zmul, v * zmul,1)


So for 160*80 times getPixel() are all against this small zone, many many times are reading the same dot. So I guess it could be a way to optimize by replacing getPixel() with getRows().
I have no time to do it today, maybe tomorrow.


It’s been a while, but wow this worked so far :eyes:. I’ve been mostly busy with school and stuff that I have not been on here, but we are very close to getting an engine to build courses on top of! Some things we might need are to be able to detect the color under the sprite, like to see it the sprite is on grass, etc. For the actual pipes, I was thinking of 2d sprites, as in the original game they also look like so, just rotating to where the player was actually facing. You might see me here and there on the forum cuz I’m busy.


Here’s an updated version that uses fixed-point math for hardware compatibility. It gets about 15fps on my PyGamer - not great but still playable, and a lot better than the previous version which ran at 0.4fps. On the emulator on my laptop, it claims to get over 200fps. (By the way, @Kiwiphoenix364, the fps value depends on the speed of your computer. Even if it gets 30fps on your computer, it may be running slower or faster on someone else’s computer.)

It’s Blocks compatible, though sadly that has a tendency to randomly rearrange code blocks and delete comments. The math/rendering code ends up in gray blocks.

The track and background art is a placeholder, feel free to edit that in the assets view. I wasn’t originally planning to add that, but I was procrastinating about starting the extra math needed to place objects on the track. I’ll see if I can revisit object placement code in the near future, but no promises.

1 Like

I worked on this some more and I have a working prototype with a customized camera, and I’ll probably implement setRows to get the fps up later (@AqeeAqee thanks for the suggestion) for the increased “render distance” of this demo. I’ll add pipes and other sprites in the future, but for now this is what I have. It has offroad, and some collision.