Pocket Burning Sand (Open Source)

C

colin9876

Active Member
Licensed User
We can have a clear pen which does remove liquids in my next version, by having it as a mod rule that pixels die if they hit the clear pen.

For the moment, we can have an icon that removes all liquids but keeps the solids. If u want that I'll tell u what to code?

For now can u please
1) Set style=3 (in the Globals rather than =1, nicer to start of with the joined up line)
2) set those icons at the right height in the form (so u dont need the code at runtime)
3) Set all the Dims (8192) 'thats multiples of 8K
4) add the line
if n>8170 then Return
just before the line n=bh1.AddElement .... in the main loop

This will stop it running out of Memory. I notice the version of PocketSand u told me about limits u to about 8000 pixels aswell, its also a good way of stopping it getting ridiculously slow

Then Zip it all up to me! Thanks
 
Last edited:
N

neilnapier

Active Member
Licensed User
Longtime User
If you are making a update I will wait until you release it. Once slight problem though. It would no be a good idea to have when something interacts with clear then it dies because the background (black) IS clear.
 
C

colin9876

Active Member
Licensed User
Dont worry the clear pen will plant very dark grey pixels(appear black) that react with all other pixels, then die themselves

Can u do 1 to 4 above plus

5) New Globals
MinX=27
MinY=27

6) and change then 26,27 in the bh1.new line to MinY,MinX (in that order because its Top,Left)
7) and change the 26, 25 in first line of main loop to MinX, MinY
if down = false OR x<MinX or x>MaxX or Y<MinY ....
 
Last edited:
N

neilnapier

Active Member
Licensed User
Longtime User
Will do. Also I forogt to tell you, in BS if you want to create a reaction with every element all you need to use is the element All.

Also incase you didn't know weight and interaction rates go from approximately 0 to 32000 (ish) when it comes to reactions and -32000 to 32000 in weight terms. All others go up to about 10.
 
N

neilnapier

Active Member
Licensed User
Longtime User
I have done everything you have requested but befroe I release it I have one or two questions to ask.

1. Can I change the 7 pixels at once thing to 20 (I already have on mine i'm just wondering if it would make it too slow for PPC)

2. I suggest changing the pensize/2 rule to Pensize*2 instead for lines because it makes a better size.

3. Do you know how to sort the gravity glitch that causes new elements to fall at there original direction while having the same element created previously falling the opposite direction. the gravity swapper should swap new elements gravity too.
 
C

colin9876

Active Member
Licensed User
1) No keep it at 7 please for PPC (after all thats what this program is supposed to be for)

2) definately not 2*Pensize - again too big for PPC. If u want to use Pensize then thats an ok compromise (its currently only half pensize!)
 
Last edited:
C

colin9876

Active Member
Licensed User
Reverse fix

If u want the reverse to work on new elements we need a
Global
reverse=1

everytime a gravity is set in the elements button code add *reverse
e.g. gravity=0.8*reverse

Then in reverse button add code lines
reverse=-reverse
gravity=-gravity
 
Last edited:
N

neilnapier

Active Member
Licensed User
Longtime User
There you go.

Not added the gravity thing because didnt see your post. I have been on the computer for hours now so I think I will have a break and come back tomorrow, so see ya!
 
C

colin9876

Active Member
Licensed User
Neil, it looks good
1)One tiny error - MinX & MinY wrong way round. AGs lib takes the screen dimensions as top,left,bottom,right so the first call needs them MinY,MinX,MaxY ...
so if u can change that, and also
2) Error in the line MaxX=Burningsand.width .. should b -30 (not -29), please change
3) add the reverse fix, & add the horiz & vert icons with the code. U could use the character ~ with font color 255,255,255 for the squigly line - saves finding an icon

Update - Ive made changes 1,2,3 in v2.8

re the circle jerkiness, may be a bit more improvement if AG can lock down smaller graphics buffer. NB 182x205 v 240x258 = 58% Worth it especially as min/maxX,min/mayX already pased as parameters!
 
Last edited:
C

colin9876

Active Member
Licensed User
Job for Joe?

Hi Joe if ur free to help would u want to write the file handling routine.

Has to load the config file which has 4 fields per record
color reacts with color and has prob of turning into newcol

e.g. (0,0,255) (255,0,0) 0.8 (100,100,255)
watercolour hits firecol and has 0.8 prob of turning into steam ...

into a Rules(MaxRecords) array
 

agraham

Expert
Licensed User
Longtime User
Colin
colin9876 said:
e.g. (0,0,255) (255,0,0) 0.8 (100,100,255)
Click to expand...
Can I suggest a symbolic colour section then a rules section.

#colour
fire 255,0,0
water 0,0,255
steam 100,100,255

#rules
fire water 0.8 steam


I assume these things a commutative i.e
fire water 0.8 steam = water fire 0.8 steam

I further assume that if the probability is not met then both particles go on as before. However if it is met do we get two particles of steam or 1?

I am thinking about how efficient interactions can be put in the library as a one time thing you guys can build on. I am thinking that you could pass an array of colours with the background colour at index 0 together with the number of colours. Also pass two further arrays representing the last two parameters of each rule together with the number of rules. Assuming the rules are commutative the index of each rule is Colour1ndex*numberOfColours + Colour2index. This allows an efficient lookup of what to do. This rule array is big enough to hold all possible interactions. Unspecified interactions just have probability set to 0. Without compromising efficiency there could be an additional outcome array. You might also want to specify a new gravity for each resultant particle - two more arrays

fire water 0.8 steam -1 steam -1

hyrogen oxygen 1 water 1 nil 0

For tidiness this stuff would be passed in an initialise call before you start calling the timer call.
 
J

JoeMaximum

Member
I'll try to do the file handling routine, i should be able to do this.

And for the agraham idea, it is really near BS1 coding, only thing is:
When making interaction it would be more like :
Water Fire Steam Clear 0.8
So this indicate the if Water touche Fire then water become Steam, and Fire become Clear at a rate of 0.8
 
C

colin9876

Active Member
Licensed User
logic.

AG,
Symbolic list useful for ease of config, but when its fed into the array doesnt need that info, just hash the rules on the colors

Yes ur absolutely right about needing the new grav, & spread values.
So (firecol,watercol)=0.9, steamcol, -1,2
The rules work the same both ways round but u only apply them to the moving particle

So its only the particle that does the hiting that changes. This actually works because if u have a stream of water onto a fire, sometimes the water hits a fire pixel and sometimes the fire hits a water pixel.
Theres a big advantage of doing it this way that u only have to look at the pixel thats moving and what its moving to.

P.s. any luck with locking down that smaller area.
Should only be a quick change? just changing the 0,0 ... to MinY, MinX etc?
 
Last edited:

agraham

Expert
Licensed User
Longtime User
colin9876 said:
Symbolic list useful for ease of config, but when its fed into the array doesnt need that info, just hash the rules on the colors
Click to expand...
Symbolic for humans. You don't mean hash, that's for reverse lookup inside the library - its colour indexing with reference to a colour array outside the library.

Should only be a quick change? just changing the 0,0 ... to MinY, MinX etc?
Click to expand...
Slightly longer and a bit more complicated than that - it's a mixture of relative and abolute indexing of pixels in the library now instead of all absolute and I got some wierd effects on my first try.
 
C

colin9876

Active Member
Licensed User
yes understand symbolic easier for humans.

thanks for new lib- going to try it in latest 2.18 version

Why wasnt it just a case of using (MinY,Minx,MaxY,MaxX) in the rectangle definition of the bitlock?
 

agraham

Expert
Licensed User
Longtime User
colin9876 said:
Why wasnt it just a case of using (MinY,Minx,MaxY,MaxX) in the rectangle definition of the bitlock?
Click to expand...
Because what was bleft, btop in the form bitmap becames 0,0 in the locked bitmap as it is a subset so all the co-ordinate references to that bitmap have to be changed, yet mouse co-ordinates for particle creation are still related to the form co-ordinate system (that's where I screwed up).
 
C

colin9876

Active Member
Licensed User
got it!

Also Im just trying to clear out my device, full up!
Also any chance u can repost that library calling it bitmaphandler3 or something, real risk of people picking up old versions of the library, as now when Im sending Neil new soucres Im not sending him the dlls? Thanks
 

agraham

Expert
Licensed User
Longtime User
Just rename it then!
 
You must log in or register to reply here.
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…