Pocket Burning Sand (Open Source)

[colin9876]

AG new library is faster.

Unfortnuantely Ive realised something which has only been apparent now Im working on the reactions.

My logic for the movement of pixels was slightly wrong

It should be two independent steps
If u can move vertically do so,
if u can move horizontally do so.

it was
try and move verticle & horizontal amounts, if u can do it
If u cant just do the horizontal amount


The difference in these two logics can be demonstrated with the following glitch in the current version
It takes a long time for a pile of water to level out

What happens top water molecule cant move down and (left) say so will just move left. but then may next try to move down and right, not be able to do it so just move right! So it goes back to where it was without falling down!

Sorry everyone, Particularly AG, can u alter that please?
It also helps with the reactions - I will explain later when I release that

[agraham]

I suppose this is really for Colin. It is a code fragment showing how I think the library might handle interaction rules efficiently.

Basically it needs an array of colours (remember that the top byte needs to be 0xFF = 256 on a PPC) with the background at index 0.
It would also need arrays of rules, probabilities, and two of colours to change the interacting particles into - one or both of which could be 0 (clear).

A rule entry would be a number - the product of one colour index * number of colurs + the other colour index - the correspponding entries in the other arrays are obvious.

The library would build a set of larger probability and change colour arrays all numcolurs * numcolours long and zero them. It would take each rule and add the probability and change colours at the rule index in the new arrays. It would also commutate the rule so it only needs to be specified once in the passed rule array.

The idea is that in the timer loop when moving a colour the destination colour is read and the rule index calculated from the particles own colour and the probability looked up. If not zero then the interaction would be calculated and performed. Cleared particles would be set to backgrgound and would percolate away as normal but invisibly. There is no chance of doing any further manipulation and retaining some decent level of performance.

Comments welcome.

[colin9876]

I'll give that some thought - sounds good. But the particle being hit cant change unless it searches thro the whole array to find what is at that x,y position Thats why I have only the hitting pixel affected. Works in practice
Hold on a bit tho before coding that lot because Im still middevelopment!

Dont like the idea of black pixels just perculating away tho. Just a line to say if pcolor=cBlack then send it to the destroy routine much more efficient. Then can use that slot in the array

[agraham]

Originally Posted by colin9876

I'll give that some thought - sounds clever. But the particle being hit cant change unless it searches thro the whole array to find what is at that x,y positiom

You're right - missed that!

Dont like the idea of black pixels just perculating away tho. Just a line to say if pcolor=cBlack then send it to the destroy routine much more efficient. Then can use that slot in the array

I thought that I found a problem with that, but I can't now think what it was so you're probably right again.

Modified logic attached - didn't see much sdifference myself however. New property DllVersion added - this one is 2.1.

[colin9876]

Nearly there, the reason u didnt notice much difference is because the logic change also needs the line re move sideways to go to
if getcol(nx,ny) <> bcolor
then nx=x(i)

Then the next bit is
if nx<>x(i) or ny<>y(i){
unplot (x(i),y(i))
plot(nx, ny)
}

[colin9876]

Sorry that really is the last change!, but that is a critical one for things to react properly

[agraham]

Originally Posted by colin9876

But the particle being hit cant change

A particle could check if it is still the same colour when it's its' time to move. Unlike the former GetPixel the pointer based GetColor should be quite a cheap operation. It could then reset its probability and gravity from arrays passed alongside the colour array in initialise. The same tables could be used by AddElement and would help efficiency a bit.

EDIT :- It could also destroy itself if it was now background

[colin9876]

ok good idea,

Back to the
move horiz
move vert

the reason the change hasnt made any difference yet is because it still only moves down if it moves horizontally. See the other line change required above!! Because the actual make the move was still within the horizontal move if statement!)

[agraham]

Version 2.2 - still looks much the same end result to me!

[colin9876]

Bumps do level out a bit faster now the logics better
The reason hills dont level out quicker is because the outer dropping particles stop the inner ones from moving - but I think thats how BS is supposed to be. Its like that in th PC version

Im very happy with how its comming along. New library is better than ever. Its running amazingly well.