slime permeability and BDCFF

Everything about the modern clones and remakes.

Moderator: Admin

Sarr.
Member
Posts: 16
Joined: Tue Oct 27, 2009 10:22 am
Location: The Netherlands
Contact:

slime permeability and BDCFF

Post by Sarr. »

welcome everyone,

i'm sure there will be someone me to enlighten me in the slime permeability matter...

there are various sources explaining how the slime works in BD and how it is being exported to a BDCFF file. i've been reading this thread http://www.boulder-dash.nl/forum/viewto ... rmeability - as well as gdash source code. however, there are some inconsistencies in that matter.

could you guys answer these questions, or/and point me to any soyrce that would help me in that case?

a) is all slime in original BD games a predictable slime that uses c64 predictable-algorithm?

b) how to determine if 'SlimePermeability' in a BDCFF file specifies a prfedictable or non-predictable slime?

i've been thinking... maybe if the value is stored in the file as a float value [with a decimal point], then it means it would be a non-predictable slime with this probability of passing-the-objects-through? and if it is an integer, i should treat it as a value 'to compafre to' when using c64 random?

i've been reading quite a few cave sets, downloaded from this web page... including original cave set from BD2, which uses a floating point style to store slime permeability... arno's cave sets also use floating point style of describing slime permeability? maybe the authors could support me here?

cheers,
Sarr.
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Re: slime permeability and BDCFF

Post by LogicDeLuxe »

Sarr. wrote:a) is all slime in original BD games a predictable slime that uses c64 predictable-algorithm?
Yes.
b) how to determine if 'SlimePermeability' in a BDCFF file specifies a prfedictable or non-predictable slime?
You use SlimePermeabilityC64 instead.
i've been reading quite a few cave sets, downloaded from this web page... including original cave set from BD2, which uses a floating point style to store slime permeability... arno's cave sets also use floating point style of describing slime permeability? maybe the authors could support me here?
In case of converted caves, it is likely a very old version, and the slime behaves just wrong. BDCFF didn't support predictable slime in the beginning. Or if it is an original BDCFF cave set, it may be just supposed to be random.
Sarr.
Member
Posts: 16
Joined: Tue Oct 27, 2009 10:22 am
Location: The Netherlands
Contact:

Post by Sarr. »

i'm sure you're familiar with many .bd cavesets downloadable from the web site. these .bd files, have a header-comment saying 'Converted using Tim Stridmann's X2BDCFF converter.' given that, i presume the source of the cave set was legit and these should be valid cave sets.

if we then have a look at BoulderDash02.bd, and think of it as a cave set that should use predictable slime, it has slime permeability defined in a following manner [examples from different caves]:
SlimePermeability=0.125
SlimePermeability=1.0
i've never seen values above 1.0, so would it be safe to assume, that this value is a 'c64' version but stored in a floating point way? eg. 1.0->255 and 0.125->32, where the results, 255 and 32 in this case are the values 'to compare to' when using c64random?
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

You can't convert the float value to integer. The C64 permeability is a byte value, but it's not an integer number. All 8 bits have the same significance. Ie. a value of 1 has the same delay as 2 or 4 or 8. A value of 3 has the same delay as 6, 34 or 129 and so on. The difference is the pattern. There is simply no way to convert that to a float.

Tim Stridmann's site is rather old, and in fact, all bdcff files with that comment got the permeability wrong. If you really need a correct bdcff file, just use GDash, select the game you want and save the caveset as a bdcff file. The demos (in case you recorded any) are in GDash's native format, though.
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

Post by cirix »

Also, it seemed to me, that many .bd files which can be downloaded are not only converted by Tim Stridmann's converter, but were also edited by hand - to add some things the converter could not handle (for example, the demo).
cirix
Sarr.
Member
Posts: 16
Joined: Tue Oct 27, 2009 10:22 am
Location: The Netherlands
Contact:

Post by Sarr. »

good to know. considering cave sets 'shipped' with gdash, were they also edited by hand by their authors?

like for instance arno sets which are having float slime permeability [files downloadable from arno web pages] but when saved as bdcff from gdash, they have a proper integer value. i've been comparing these and i can't figure out how the transformation could be done automatically - there are few different integer values corresponding with one float value.

another possibility would be that these were re-imported from c64 disk images [or another 'original' source]. that would make sense, because who would be editing cave set and introducing bugs [like wthese with random fill elements in BD3].

who would know this ancient history - how was it?...
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

Post by cirix »

Sarr. wrote:good to know. considering cave sets 'shipped' with gdash, were they also edited by hand by their authors?
No, those are all converted automatically.
Sarr. wrote:like for instance arno sets which are having float slime permeability [files downloadable from arno web pages]
You cannot convert those.
This is how it worked on the C64.
- generate a PREDICTABLE random number.
- use binary AND with the number generated and the slime permeability.
- if the result is 0, let the stone/diamond pass.

This is why 1, 2, 4, 8... refer to the same probability of passing (50%, as one bit can either be 0 or 1), but a different pattern (due to the predictable random numbers). So you might convert the probability, but you cannot convert the exact pattern to a floating point value (check afl boulder dash, cave 15 for an example where it is needed).

The random number generator is the same as the one used for generating the caves. In object-based levels (for example, BD2), the seed value is whatever left in the random number generator after drawing the cave. In map based caves, the value is 00 1E (i found this using disassembly of afl boulder dash). Check caveengine.c:2306, caveobject.c:1401 in the GDash source. Also check docs/c64_internals:153.
Sarr. wrote:how the transformation could be done automatically
The probability of passing is 1/2^(number of 1's in the integer permeability). But that destroys the pattern.[/quote]
Sarr. wrote:another possibility would be that these were re-imported from c64 disk images
The caves shipped with GDash are like these - they are slightly different from the Arno web page versions.
cirix
Sarr.
Member
Posts: 16
Joined: Tue Oct 27, 2009 10:22 am
Location: The Netherlands
Contact:

Post by Sarr. »

yeah. i'm pretty much familiar with the c64 predictable random and how it's being used for the slime.

00 1E as a begin seed - that's new for me. good to know, again. recently i read gdash code once in a while, it's like a good book to me - i must have skipped that part...

i've been just wondering how these float values in some bdcff files were created - now i know. no pattern - that's a valid point.

now, out of curiosity, how were the values for the 'original' (like BD2) games calculated? how do we know they're 100% accurate? [apart from running gdash and vice side by side][/quote]
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

Post by cirix »

Sarr. wrote:now, out of curiosity, how were the values for the 'original' (like BD2) games calculated? how do we know they're 100% accurate? [apart from running gdash and vice side by side]
Exactly like that. :) For example, BD2 cave E is a good test cave for this. But for the game to be perfect (at least to a reasonable extent) - I had to do the disassembly.
cirix
Volutar
Member
Posts: 10
Joined: Wed Mar 25, 2009 11:20 am
Location: Nizhnevartovsk, Russia

Post by Volutar »

By the way spectrum and atari/commodore BD versions of BD2 have slightly different scenario for the same cave (AFAIR, cave E). The difference is caused by lower size of generated cave. Spectrum version generates only 20 lines of cave, but atari/commodore generates 21 lines. So static RND generator for the moment of level start is different.

Anyways - all these scenarios can be easely achieved and reproduced perfectly in frame-by-frame basis.
Sarr.
Member
Posts: 16
Joined: Tue Oct 27, 2009 10:22 am
Location: The Netherlands
Contact:

Post by Sarr. »

slime, my nemesis, comes back...

my predictable random number generator works fine, it generates the proper cave random layout and i'm not reseting it afterwards [also, i'm setting the proper seed value for map-based caves]. then the slime takes over and... for some strange reason, with some predictability values works fine, but with other ones not. the pattern becomes different compared to the same cave played in GDash. i'd understand if it worked for all, or not worked for any, but in this case, i have no idea what it might be.

did any of you face such behavior?
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

Post by cirix »

Sarr. wrote: my predictable random number generator works fine, it generates the proper cave random layout and i'm not reseting it afterwards [also, i'm setting the proper seed value for map-based caves]. then the slime takes over and... for some strange reason, with some predictability values works fine, but with other ones not. the pattern becomes different compared to the same cave played in GDash. i'd understand if it worked for all, or not worked for any, but in this case, i have no idea what it might be.
be careful how you use the random number generator. the c64 cave is 40x22 cells. the random generator DOES NOT fill the first and the last row; ie. it only fills (0,1) to (21,39)! (0,0) is upper left, (39,21) is lower right.
maybe this is the problem.
cirix
Sarr.
Member
Posts: 16
Joined: Tue Oct 27, 2009 10:22 am
Location: The Netherlands
Contact:

Post by Sarr. »

sure i know about first/last row being skipped, righto. however, my ramdom number generator seems ok - as i've mentioned, it generates cave random elements layout perfectly - that would be already wrong if the sequence was not right. simple, yet enough for testing, this is my test-cave:

[BDCFF]
Version=0.5
[game]
Name=SlimeTest
Author=Sarr
Date=2009-11-23
Levels=5
[cave]
Name=Slime
Intermission=false
Size=12 12 0 0 11 11
Colors=Black Black Orange Brown Gray1 Green Blue
DiamondsRequired=10 10 10 10 10
DiamondValue=0 0
CaveTime=999 999 999 999 999
CaveScheduling=ms
FrameTime=180 180 180 180 180
CaveDelay=0 0 0 0 0
InitialFill=SPACE
RandomFill=BOULDER 255 DIAMOND 128 DIRT 0 DIRT 0
SlimePermeabilityC64=249 0 0 0 0
[objects]
FillRect=1 6 10 10 SPACE
Line=1 5 10 5 SLIME
Point=0 10 INBOX
Point=11 10 OUTBOX
[/objects]
[/cave]
[/game]
[/BDCFF]

i'm testing always level1. just playing the cave, not moving, comparing GDash versus my project. i'm changing SlimePermeabilityC64 value each time. i've started from 255, then, 254, 253, 252, 251, 250 - these are playing exactly the same as GDash. 249 is playing right to some extent, then the pattern is broken for no apparent reason, 224, 192 for instance play entirely different. i'll go down with the values, maybe i'll see some pattern in that. unless anyone has some other suggestions.

it's a simple bitwise AND, i don't get why it does work for just few numbers and not for some other ones. it's odd. or i'm blind.
User avatar
cirix
Member
Posts: 284
Joined: Fri Feb 01, 2008 11:00 pm
Contact:

Post by cirix »

Sarr. wrote:i'm testing always level1. just playing the cave, not moving, comparing GDash versus my project. i'm changing SlimePermeabilityC64 value each time. i've started from 255, then, 254, 253, 252, 251, 250 - these are playing exactly the same as GDash. 249 is playing right to some extent, then the pattern is broken for no apparent reason, 224, 192 for instance play entirely different. i'll go down with the values, maybe i'll see some pattern in that. unless anyone has some other suggestions.

it's a simple bitwise AND, i don't get why it does work for just few numbers and not for some other ones. it's odd. or i'm blind.
I'm almost completely sure that it has something to do with the binary and thing.
The formula is: if c64random AND permeability = 0, then element passes.
Be sure to check the following things:
- the c64random is an 8-bit unsigned integer value. if you use C, be sure to write unsigned char, not just char; the simple "char" type is usually a signed type (on most compilers; -128..127). do this for both the random number function and the slime permeability value.
- ALWAYS generate a random number, not just when you have checked that the element is able to pass. for every slime, a random number is generated, ONLY THEN it is checked, if there is some stone or diamond above it which can pass, and if there is space below it, so the thing can pass. if there is nothing above the slime, a random number is still generated!
- do the random number generating for the slime, not for the stone or the diamond. to put it in other words, it is the slime which checks whether it will move the stone above itself to the cell below. it is not the stone which checks if there is slime below. think of slime as an active element. (in this sense, the magic wall is inactive element. for the magic wall the stone checks the presence of it during falling!!)

the number of random numbers generated in each cave scan therefore is equal to the number of slimes in the cave - one number of each, not depending on what diamonds/stones are above slimes, not depending on anything.

btw, afl boulder dash cave 14 (various/afl in gdash cave collection) is another nice example to test slime. in that cave, you have to run fast, or you won't have time to pass the small corridor - the stone falls down, and the expanding walls close. that was the exact cave which convinced me to try to understand slime fully - afl boulder dash was the first boulder dash ever in my life :) and i liked it.
cirix
Sarr.
Member
Posts: 16
Joined: Tue Oct 27, 2009 10:22 am
Location: The Netherlands
Contact:

Post by Sarr. »

hi,

i'm still struggling with the predictable slime [whenever i have few spare minutes ;]. i've double checked my code against gdash code, i've checked everything that cirix had mentioned before. i can say i'm using pretty much the same approach.

i've noticed that the lower the permeability value, the quicker the pattern becomes different from what i see in gdash. resulting in the perfectly accurate pattern for permeability 255 for instance and broken already in 'the 3rd line of falling elements' for permeability 128. odd.

now something i'd like to ask the mighty cirix ;] i'm logging out something like that [what you see is the first scan of the map]:

10/01/03 23:43:22 > Step[000].Rand[246].Perm[128].Result[0]
10/01/03 23:43:22 > Step[000].Rand[005].Perm[128].Result[1]
10/01/03 23:43:22 > Step[000].Rand[222].Perm[128].Result[0]
10/01/03 23:43:22 > Step[000].Rand[064].Perm[128].Result[1]
10/01/03 23:43:22 > Step[000].Rand[108].Perm[128].Result[1]
10/01/03 23:43:22 > Step[000].Rand[226].Perm[128].Result[0]
10/01/03 23:43:22 > Step[000].Rand[097].Perm[128].Result[1]
10/01/03 23:43:22 > Step[000].Rand[042].Perm[128].Result[1]
10/01/03 23:43:22 > Step[000].Rand[061].Perm[128].Result[1]
10/01/03 23:43:22 > Step[000].Rand[026].Perm[128].Result[1]

would it be possible for you to take the map i've mentioned earlier in this thread, add this kind of similar log out to gdash, run the cave for few different permeability values [128, 192, 224] and send me the results?

i'm posting that here, since i wasn't sure whether this sort of a message should have been posted on prive or not. this really bothers me and i'd really like to nail the problem.

BR,
Sarr.
Post Reply