Pocket Burning Sand (Open Source)

Ive made a logic error

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

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.

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

colin9876 said:

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

Click to expand...

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

Click to expand...

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.

fantastic but

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)
}

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

colin9876 said:

But the particle being hit cant change

Click to expand...

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

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!)

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

Just out of interest

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.

Colin - I would put the dll version checking before the new and telll the user which version was expected. I also wouldn't let the app run further as if (as is quite possible) the parameter lists of the functions change then the user would get a runtime error.

Problemo

Can stop it continuing but Cant check the ver before the bh1.new1 call. It says object must be first created?

Going well. Once horizontal and vertical lines are sorted and reactions then this will litterarly be a mini BS.

BTW, Ice is supposed to be solid, there is no snow in BS.

EDIT: Also does the larger pensizes create more pixels of the liquid or just spread them out more? When I count them they always are seven (default) Could you please change this?

colin9876 said:

Can stop it continuing but Cant check the ver before the bh1.new1 call. It says object must be first created?

Click to expand...

True!

Changes

Neil, changes done.
u now get pensize+3 pixels per time!
Ice is a solid

Do u want to add the horizontal and vert lines, and post it in a Zip with the dll v2.2
By the way I keep changing the brown walls to slightly lighter so they r better to be seen on my PPC & u change them back!!

By the way Im so impressed with the Library. This is on par with the commercial PocketSand now

Neil

I notice u removed a couple of features I added yesterday
e.g. screen note of current pensize and fill type etc

when playing on the ppc its really useful to know whats currently selected

Can we have anything like that?

Even if the current Icon was just highlighted that would help?

Have you noticed that sometimes the pen goes out the border? I will add the lines but I will do them later this weekend because i am busy tonight. Also on the next update is it OK if I make it so that the element on the top of each menu is activated when their group is selected 9you can do it if you want) Also can i re addthe Blue border to each of the icons when they are selected so that it adds to the realism of the real BS.

Thanks.

BTW are we making all the elements or are we just going to revove all these when modablility is made?

Yes blue border would be good! Borders round things that are selected would be helpful.
Just make the icon slightly bigger than the picture, e.g. 20x20 as the pics are 18x18, then set the background colour on it, and toggle the transparent=False when selected! Much better can see what ur doing then!

Much better

The pens and sizes have borders on now when they are selected. Easier to see what ur doing!

Amazing

Neil u'll like this.
Using the power of the new Lib Ive been able to add constant sources - Try the gas burner, or the rain cloud !

Even works with pensizes so u can have a very heavy raincloud! U can only have one continuous source at a time at the moment but its a nice addition

How about u release all this now under ur next version number on the front page then I'll push on with reactions next week?