Pocket Burning Sand (Open Source)

colin9876 said:

Will we both have the SAME indexs and reverse look up results?
Also in Basic what calls do I use to hash and reverse look up? Thanks

Click to expand...

Sorry but I don't get what you are after - The user of a hashtable doesn't hash anything, the hash values are not visible. The hashtable does it for you and just looks like a key & value dictionary pair. Tell me what you are thinking of doing?

colin9876 said:

Yes I was wondering how he maps 200% to a 5 fold increase lol!
Still hes right about a problem running it now on the PPC - any ideas?

Click to expand...

No I've no ideas 'cos I'm too shagged out after 6 hours driving and a wedding reception today.

Neil, dont think maths is ur strong point. Even with ur way of reading it 800% faster would nly be 9 times the speed!

AG
Maybe I got the word wrong but I thought u could get a function to take big num down to a small one. Whatever the crunching look up whatsit is called, it requires R,G,B colors to go to Indexing Ints 1,2,3 ....
Then I would need a reverse function to get back from the Index to the color, but that must be impossible as u cant get compression out of nothing as its not a 1 to 1 mapping. If it just stored as a dictionary pair it must be slow because it has to look through the whole list of RGBs to find its Index on reverse look-up?

My condense routine works really well, also doesnt need a look up table so Ive used that. Simple as well, as long as u dont pick any two colours closely similar. all 3 RGB's reduced DiV 64 so (R,G,B) (4*4*4)=64 COLOURS

RGB -> index = R/64*16 + G/64*4 +B

Plus having the rule crammed into a double makes passing the array easy!

Problem with the PPC version is the bit Im now totally stuck on.

colin9876 said:

Theres nothing to do what I want. Infact must be imposible as u cant get compression out of nothing so there cant be a revese 1 to 1 relationship

Click to expand...

Single index number looks up big numbers from an linear array. Hashtable or dictionary use Key/value pairs to get ordered little numbers (indexes) from big/random ones. Standard computer science stuff. What do you need that's different?

If it is 100% faster then it IS faster... for example if you have a product that you sell so you get 100% profit as a percentage from the cost price then if you spent £1 making it then you would sell it for £2... If it is 100% then it is 100% added on to what is already there... which is doubling.
0% faster is the same not 100%!!!

This is because it is 100% FASTER NOT 100% of the speed!!!

Maths is one of my strong points!

Reverse

All I wanted was a fast way to get back from a color to an index. With an instant function.

If it has to look through a table (MaxCols long) it May have to check Maxlong records before it gets a hit?

My condense function gets the index immediately

Going back on topic, no one has found out why it isn't working have they?

This is a real problem... the program can't continue if it doesn't work.

Yes ur right, Im having a real mental block with that.

AG when u add a dll do u have to manually add the bh1 object aswell?

colin9876 said:

All I wanted was a fast way to get back from a color to an index. With an instant function.

Click to expand...

Within a .NET library it is called a Hashtable or a Dictionary - trust me - it's efficient! In B4PPC there isn''t access to a either but I could provide it with library calls.

BTW I think the problem is a Compact Framework limitation - more tomorrow, my bottle of wine is nearly half empty now and past experience tells me to stop now or I'll end up redoing everything tomorrow! Good night.

AG- rule parsing

Dont worry about writing any hash routines, condensing method RGBs each div 64 is simple and fast.
Though if u could alter how grav&spread are stored it would be majorly more efficient-

Was thinking how wasteful it was to have Spread, and gravity each as doubles.
Combined both into an INT, 8 bits each. This gives major improvement, also means rule change can be passed through simpliy, and stored in array of Doubles

Can we get rid of gravity and spread and have INT gravspread
**
8bits gravity (1 bit sign, plus 7 bits for 0-100) '% chance it will move up or down
8bits spread (0-100) '% chance it will move left or right
**

all logic is now
if rnd<gravbits/100 then move +1 or -1 depending on sign
if rnd<spreadbits/100 then move either -1 or +1 horizonatlly

This gives huge improvements, in memory usage. Also makes the Rule which is kept in a double so simple to pass over

RULE
**
8 bits probabilty (0-100)
8 bits newindex
16 bits newgravspread
**

Then rule change is
if rnd<probabilty/100 grav then
{ index= newindex
gravspread=newgravspread }

AG question. If gravity stored as a signed 8 bit int can c# cope with those?

Colin - you are going down the wrong track. For God's sake stop trying to be too clever and just do the straightforward thing.

I obviously haven't got the hashtable through to you and you don't seem to have bothered to find out about it because you say "Dont worry about writing any hash routines" - you DON'T write hash routines - it all happens invisibly for you. Hashtables and Dictionaries are .NET objects provided for your use.

Your condense is not as efficient as you think as it involves several arithmetic operations and there is absolutely no point in burning processor cycles to compress stuff to pass to a library that then burns more cycles getting it into state that can be used. In fact you probably end up using more a little more memory doing that.

In this context of limited processing power your ideas of improvements are not improvements at all and you appear to lack the knowledge and experience to judge what are real improvements in this scenario.

The library problem was an undocumented difference between the full and the compact Framework. The full lets you lock parts of a bitmap whereas the compact will error unless the locked area is equal to the full extent of the bitmap. Version 2.21 here is equivalent to 2.1 but with a bit of inlining that probably doesn't make much rnoticeable difference.

EDIT :- Sorry, managed to post the version that proves the problem rather than the one that solves it. The one that works is now here. If you downloaded before seeing this edit then download again.

colin9876 said:

AG when u add a dll do u have to manually add the bh1 object aswell?

Click to expand...

Tools -> Component .. to add the library

then at design time

Tools -> add Object to add an instance of an object from a library

or at run time, though libraries must have been added at design time

AddObject(...)

Thanks

Thanks for re doing that library, looks like all that asking I did to push u to lock down a smaller area of the screen was a waste of time then. Im sorry about that:sign0161:!

As to getting the rule into a Double, and having gravspead as 16bits in an Int, I still think thats a good idea. I will go and research these look up tables and methods and report back! ,,,

Neil - In ur code please can u change the check for the version number to 2.21 so it works with the latest library

colin9876 said:

As to getting the rule into a Double, and having gravspead as 16bits in an Int, I still think thats a good idea

Click to expand...

Why? What do think it achieves?

Neil - In ur code please can u change the check for the version number to 2.21 so it works with the latest library

Click to expand...

It works anyway as the check is a "less than" - I ran it without change to check that the library worked on a PPC.

Nice. Still works quite fast and the sources work well. Perhaps when you release the next version colin could you change the sorce thing in the appstart to false so it doesn't start when you first open the program.

How long do you think it will take till you release your next update?

EDIT: Also I still think that clear could work better to remove elements. Once a stable version is complete as it works on both PPC and PC do you think its name should be changed from PPCBS to MiniBS?

EDIT2: when you release your next update can you make it so that the top of each group is actived when that group is selected?

EDIT3: There is a small glitch in that liquids will clear solids that are slightly above them.

Just to let everyone see the comparison of BS and PPCBS

Neil

1) MiniBs - good idea
2) Top of group activated - good idea - I was finding it a pain having to click twice to get wall!

3) Clears one pixel above liquid? Give me an example where it happens.


Re next release: Ive got everything working in Basic, but now need the last addition to the library. Im utterly convinced that using 32bits each to store the spread, gravity etc is a waste - and by fitting these into less bit can get the whole rule into a Double so the array of rules is a simple array of Doubles.
rule is 4 lots of 8 bits representing
Probability
Index
gravity
Spread


This means a few last changes to the library - but it will eventually be better for it. And makes somethings simpler
I will put the list of alterations, with the extra couple lines for the collision to AG next week. Im currently doing a bit of homework into lookup tables so Ill get back to AG when Im sure I know what Im talking about!

While sources are on draw a striagt line down the screen underneath one of the sources.

With all this stuff being added creating the modding will be hugely difficult I believe. You would need to, for a group, tell it that when it says group to create an icon on the left hand side that when activated changes its transparency and will make the elements with in its group become visible, change the transparency of the element at the top, make sure they are in the right order, make it stop if another gorup is selected and much more.

And that is one of the simpleist parts of our program so far.

colin9876 said:

3) Clears one pixel above liquid? Give me an example where it happens.

Click to expand...

He may be referring to the fact that particles can exhibit quantum tunnelling if their spread is more than 1 - then he may not be!


You may be interested to know that I now have access to the version 6.00 beta and that 2.86 compiles and runs fine. The user interface is a bit more lively but still a bit sluggish - the library performance is unchanged but that was always going to be so. I'll ask Erel if I can post it.