Yea, I love powder game and is one of my several inspirations. BTW, here's the link:
http://dan-ball.jp/en/javagame/dust/The "secret"(s) to making a good sand game:
First and foremost, you must make a decision:
Am I going to use particle or pixel physics.
QuickSand uses pixel physics.
What are pixel physics? And what are particle physics?
Pixel physics are easier and much faster.
Particle physics are slower and harder, but allow for much more detailed physics.
Pixel physics is where you have an array holding data for each pixel on the screen, recording what element is there.
Particle physics uses objects (Types to us Blitzers) to record all the particles
Some of the many methods I use for speed, and what things slow it down for your reference:
I use trig and floating point integers in only two places, neither of which is a major component of the game. Floats are slow, so don't use 'em.
For...Each loops are pathetically slow in BlitzPlus. So I have a cool solution: I have a type for the different kinds of reactions to make them more flexible. QS was quite sluggish when iterating through each and every reaction just to find the ones assigned to the element it's checking for. So to fix that, I have a bunch of references so that it is no longer necessary to go through them all. It's difficult to explain, but if you really want it, I'll post the code for this part.
Use as few loops as possible, they make your code, when done correctly, easier to look at, and faster to operate. For example, instead of doing something like this:
;Assign a bunch of numbers to 0
For i=0 To 7
x(i)=0
Next
;Assign some other bunch of numbers to 0
For i=0 To 7
y(i)=0
Next
Do this:
;Assign two variables to 0
For i=0 To 7
x(i)=0
y(i)=0
Next
It may seem trivial, but it adds up.
Use the code archives.
I was able to find integer only line and circle functions in the code archives, and after some minor modifications, they fit my game perfectly. It's a whole lot faster than drawing to a buffer with blitz drawing commands, scanning the pixels, then putting them on the sand buffer, like I might have done was it not for the functions I found.
Lock the buffer when drawing. This should be obvious.
If an element has no reactions assigned to it, don't check it for reactions. If it has no physics assigned to it, don't update it. Wall has no reactions and no physics, so the program just skips right over it.
But perhaps the most speed provoking thing I did is how I draw elements. I call it the "Never Cls Method". Instead of draing all the elements each loop, when they need to change color, I draw them, and under no condition do I draw it otherwise.. when a pixel falls, I simply swap the two pixel's data and draw those two. This saves so much speed, it's insane. This is much harder, if not impossible, to do with particles.
Well, there you have some of the secrets.
But the most difficult thing was DEFINITELY making it so when you draw an element, lines connect your last mouse position with your latest. Download an earlier version and try to draw an element to see what I mean.
