s(l/n)ow algorithm in processing
category: code [glöplog]
O hi,
I know most of the stuff you guys code is way over my head or filled to the bone with strange vector math ;), but I found the motivation to play around a little bit in processing and while I know most of the stuff I need to learn is written in the various examples and tutorials which are available elsewhere but here we go:
I tried to code an effect which ahs been done hundreds of times before, in and outside of demoscene-contexts: a snow algorithm that lets flakes fall from the sky and eventually puts them to rest on the screen-border or (enhancement for v2!) on an obstacle somewhere on the screen.
My idea was to use a dynamic ArrayList of snowflake objects but there are several problems to overcome: for one the update/routine gets awfully slow with more flakes on the screen (of course depending on resolution of the canvas) and for the other my idea of storing snow-height per column doesnt seem to work for some reason. The basic idea was to use a static 1 dimensional array corresponding to the canvas-width and store the y-coord of the last snowflake collision there so the falling ones know when to stop/be removed...
At the moment im not sure if my approach makes too much sense at all and can be further optimized, if its just a question of setting the parameters (like nr of flakes) right or if its just plain stupid to attempt something like this in processing/pure software rendering on todays screen resolutions but oh well...
So if you feel like reading some javacode that looks like it has been written by a naive 14 year old for his first computer class, by all means go ahead and share your thoughts!
I know most of the stuff you guys code is way over my head or filled to the bone with strange vector math ;), but I found the motivation to play around a little bit in processing and while I know most of the stuff I need to learn is written in the various examples and tutorials which are available elsewhere but here we go:
I tried to code an effect which ahs been done hundreds of times before, in and outside of demoscene-contexts: a snow algorithm that lets flakes fall from the sky and eventually puts them to rest on the screen-border or (enhancement for v2!) on an obstacle somewhere on the screen.
My idea was to use a dynamic ArrayList of snowflake objects but there are several problems to overcome: for one the update/routine gets awfully slow with more flakes on the screen (of course depending on resolution of the canvas) and for the other my idea of storing snow-height per column doesnt seem to work for some reason. The basic idea was to use a static 1 dimensional array corresponding to the canvas-width and store the y-coord of the last snowflake collision there so the falling ones know when to stop/be removed...
At the moment im not sure if my approach makes too much sense at all and can be further optimized, if its just a question of setting the parameters (like nr of flakes) right or if its just plain stupid to attempt something like this in processing/pure software rendering on todays screen resolutions but oh well...
So if you feel like reading some javacode that looks like it has been written by a naive 14 year old for his first computer class, by all means go ahead and share your thoughts!
A linked list is always slower than a static array, and it also occupies more space given that it has the same number of elements. It should be used only if you need to be able to quickly insert values somewhere in the middle. This is the only use case in which it is superior to a static array.
Go with the static array. It serves the purpose.
Go with the static array. It serves the purpose.
1.) What Adok says is not completely wrong, but rather irrelevant in his case. :)
2.) This right here:
is really, really slow, esp. in SW rendering in Java, on a canvas; Use pre-computed/cached sprites for this;
3.) Annnnd:
Use HW rendering. Aka "fullScreen(P2D, 0)" :)
2.) This right here:
Code:
//display function that actually draws our flakes
void display() {
fill(255);
ellipse(x, y, size, size);
}
is really, really slow, esp. in SW rendering in Java, on a canvas; Use pre-computed/cached sprites for this;
3.) Annnnd:
Code:
fullScreen(0);Use HW rendering. Aka "fullScreen(P2D, 0)" :)
Quote:
1.) What Adok says is not completely wrong, but rather irrelevant in his case. :)
yeah i was wondering how to static array with a dynamic number of objects
Quote:
2.) This right here:
Code://display function that actually draws our flakes void display() { fill(255); ellipse(x, y, size, size); }
I see hmm, guess I need to look at how sprites work in processing then or just use single pixels (or 2x2 of them).
Quote:
Use HW rendering. Aka "fullScreen(P2D, 0)" :)
Okay, that was a quick one and gave quite the speed improvement even on my intel HD gfx. Didnt think it was that easy...
Thanks for now, Im sure Ill crack my head over the next trivial problem eventually =)
Static array with a dynamic number of objects is no problem: You start with element 0, then element 1, etc., until you reach the end of the array, then you roll back to element 0. You just have to make the array big enough so that whenever you reach the end, enough elements will have already reached the bottom of the screen so that you can safely overwrite them.
^ ...and they disappear, because they're not being rendered anymore. He wants the snow particles to stack up.
if you go single pixels with processing, access the raw pixels instead.
look at loadPixels() and then modify the pixel array as needed. very fast!
look at loadPixels() and then modify the pixel array as needed. very fast!
here's a JS version i did some years ago: http://low.fi/~visy/snow/
Use what I described but store the snow that has already dropped onto the bottom in a separate data structure (an array sized the width of your screen in which you store the height of the snow that is lying on the bottom).
The actual point to make here, is, that all the head-scratching over the performance of ALs is moot, because these are not your CS 102 linked-lists anyway. They perform reasonably well, unless you edge-case the heck out of them.
When in doubt, measure what's going on and act accordingly. In this particular case the bottleneck was the rendering, not the data structures.
(oh, and there's stuff like p5js; still very much a work in progress, but might have a future. ;)
When in doubt, measure what's going on and act accordingly. In this particular case the bottleneck was the rendering, not the data structures.
(oh, and there's stuff like p5js; still very much a work in progress, but might have a future. ;)