Faster alternative?
So I wanted to recreate
But even with just 2 elements,air and sand,this is lagging to h**l.
I wanted to do it in C++,but the usage of graphics.h is too complicated.
I wanted to do it in JS,but the environment setup was such a hassle.(make a canvas,then add an event listener,then quit)
I wanted to do it in Python,but turtle is 100000000000000000000000000000x slower than snap

if no one replies i will use js

C++ is good for graphics using Open GL (graphics.h is very slow). The only thing is that you have to install all the Open GL libraries which is a bit annoying. Once you've got it setup using it is fairly easy and straightforward.

yeah thats why im not using c++

It's your tpt timer script pic algorithm that's lagging.
See the results of a timer I built into your code: Snap! tpt timer (

Your current approach, visiting each and every item within the "stuff" table, is extremely time-consuming. There must be several things you can do to update the speed (and even increase the image's resolution at the same time). E.g. keep a list of topmost items; those are only 60 (in your implementation), not 2700.

(ps:its not good to put warps around forever loops or waits)


Why not? - there is no competing script around

You can move to a different language / development environment, and your code may run perhaps 5 times less sluggish. Or you can rethink your approach of the problem (such as, for starters: keep a list of topmost items of each column :slight_smile: - and ignore all others, since nothing is going to happen above or beneath), and it will run so fast you won't notice any processing time is being spent at all.

there is----the background script
you are actually creating lag by reducing screen refresh rate

i did and it works like a chime
(dont click on the water button,its supra buggy)

Great job! Such a difference.
So you changed over to a different environment?
Just out of curiosity ... which one is that?
And is the algorithm essentially unchanged, or did you make an improvement there as well?


nothing changed except i didnt use hyperblocks for drawing because there werent any

Keep in mind too that that program is using OpenGL so has direct access to your GPU, so it's going to be faster than snap.

What your goal should be is porting as much of it across as you can and then adding WebGL capabilities. Snap can do WebGL because Beetleblocks can. So you could add that first and then port that way.

Jens has said that Snap has no ceiling, and porting something like Powdertoy across would prove that fantastically well.

I've been meaning to port quake across to snap for a while. Not to publish it, because quake has content that's not really suitable for the age range that snap is primarily targeted at, but mostly to prove it can be done, but I have a LOT of ambition and very little skill. I can't read text languages and I can't wrap my head around codification. (Right, done with editing. I hope)
The thing with Quake, is it was written in C AND has a mini interpreter in it called Quake C. Which means you can code things in C and QuakeC will read them as things.

So, having Snap run quake and then having quake run snap? Would be super impressive.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.