Pocket Burning Sand (Open Source)

[agraham]

Originally Posted by colin9876

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

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?

[agraham]

Originally Posted by colin9876

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?

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

[colin9876]

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.

[agraham]

Originally Posted by colin9876

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

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?

[neilnapier]

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!

[colin9876]

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

[neilnapier]

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.

[colin9876]

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?

[agraham]

Originally Posted by colin9876

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

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.

[colin9876]

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?