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) => {
})
myRenderable.destroy();
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.
2 Likes
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.)
5 Likes
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
@kwx
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.
2 Likes
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.
2 Likes
It’s been a while, but wow this worked so far 
. 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.
2 Likes
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.
2 Likes
Oh, more contributions, this is great! And since last time I posted I have learned Lua, and a little bit of JavaScript, Wich means I can now help a bit more with this!
That actually looks better than any of the attempts at rendering on here, why not make the game based off of that, just make the road a bit wider, shrink the car down to a reasonable size, and add come CPU drivers and we got ourselves a mario kart
1 Like
Thanks KWX, I implemented your new engine, and it has a better fps now!
2 Likes
@Kiwiphoenix364 - can you try the v1.6.2 version I posted earlier, and see if that’s faster on your computer also? That should be a lot more efficient since it switched to updating horizontal lines with a much faster calculation (just additions instead of multiple lookups and multiplications). Unfortunately it’s not really feasible to switch that to setRows since that isn’t compatible with updating horizontal lines, but I think it’s still faster.
The reason for updating horizontal lines is because those all have the same depth value which simplifies the math. In theory it would be most efficient to turn the screen sideways to do same-depth lines with setRows, and that could work on hardware where you can turn the device sideways, but would likely lead to neck strain on a PC.
@AqeeAqee - I thought about adding a check to only look up the source texture if the u or v value has changed. However, conditional statements in an inner loop can also slow things down, so it’s not obvious to me if it’s worth adding that. Looking up the same pixel multiple times should be fairly quick since it’ll be in the CPU’s cache - the slow part is doing random memory access where it needs to load data from main memory.