Boulder Dash Forum

[cirix]

[subotai]

No, I have no question for the moment
Thank you cirix for your exact description. That helped me much. My SlimePermeability works accurate now.

For everybody who's interested I'd like to show, how you translate the PLCK values. In PLCK games, the slime permeability is stored in a value between 0 and 8. Look at the binary code to understand how it works:

[LogicDeLuxe]

[cirix]

[subotai]

Just check it out. I especially compared it in SendyDash01 Cave06. Export the game in Gdash to BDCFF, change the Slimepermeability in the BDCFF-file and compare the orignal game in Vice step by step with Gdash (the engine in Gdash works perfect concerning this). You can also just generate any cave that contains slime and check, if it behaves exactly the same in both engines. The cave delay doesn't have any influence on the SlimePermeability.

[cirix]

[LogicDeLuxe]

As far as CLCK is concerned, the 0-8 is calculated on the fly and then the actual pattern value is stored with the cave data. It really only affects the PLCK import.

[subotai]

I have no skills in assembly. So it took me a few hours to find this out. What a waste of time

@Sarr.
If it still doesn't work in your game, you should maybe also check your implementations of the other elements. In my game it didn't work first only because the explosion of the elements wasn't accurate.

[Piter]

Hi!

Now I have similar problem to Sarr and I'm stuck with it. I'm writing BD clone in C++ and predictable Slime permeability doesn't work as desired.

As far as random number generator itself is concerned I'm almost sure it works perfectly. I've checked it against many different caves and didn't see any mistakes.

Problems started when the slime came in. Again - I've tested several caves (especially E from BD2) and compared it against GDash and Atari emulator (if possible). I've also created map-coded cave in GDash and ported it to my clone. Just to be sure I begin with the same random seed values in this case (00 1E).

Regardless whether the cave is random based or map-coded I've found not always the pattern is being followed precisely. For example for higher values like 252, 248, 240 it seems to be working, but for 224 (as also cave E has) pattern is quickly broken.

Here is what I do after cave is loaded & decoded. If it was map-based I set manually random seed values to 00 1E.

1) I iterate from top left corner (0,0) field by field, line by line and check what is in this position

2) If there is slime I do in this order:

-mark this field as "scanned this frame"
-generate random number
-bitwise sum this number and permeability value (AND)
-if result was 0, then pattern is OK. "Slime" checks whether there is stationary boulder/diamond laying on it and free space below. If so - it allows it pass and marks it as _falling and delayed(scanned this frame)_.

3) Generally that's it.

Here is precise code for how I handle slime with my comments.

[subotai]

As already said, also check the implementations of the other elements (explosions f.e.).

[Piter]

Yes, Subotai, I have already read this whole topic and so far I wasn't able to figure out problem in implementation of other elements :/

Let's look at Cave E in BD2 - there are only few objects - boulders, diamonds, space, dirt and steel wall... I really don't have idea what might be wrong here.

Ok. Let's stick to boulders/diamonds algorithm - correct me if I'm wrong.

1) scanning "Standing boulder" behavior

-checks if it has has space below (FAILED)
-checks if it can roll off (FAILED)
-remains stationary (BUT NOT DELAYED (scanned this frame), RIGHT?)

2) scanning "Falling boulder" behavior

-checks if it has space below (FAILED)
-checks if it has magic wall below (FAILED)
-checks if it has something explosive below (FAILED)
-becomes stationary (AND DELAYED)

We assume that slime can pass only stationary boulders and diamonds. And not delayed, right?

So let's consider following scenario:

(... scan goes ....)
1) Falling boulder is encountered that had landed on slime frame. It became stationary boulder with delayed state.

(... scan goes ...)
2) Slime is encountered. Random number is generated. Pattern matches. Stationary boulder is now sitting on it, BUT IT WON'T PASS since it is DELAYED?

(... frame ends ...)

Am I getting this right? I might be close to the solution if Boulder/Diamond to fall MUST BE STATIONARY and NOT DELAYED?

EDIT: does anyone can provide me with RandSeed values for cave E/1 (BD2). I mean what are these two values when cave begins.... I might have other lead... In my game values are AE E8. Maybe here is a bug
Best, Peter

[LogicDeLuxe]

[Piter]

Thanks for answer, Logic. I just wanted to be sure. Slime in my implementation doesn't check whether item laying on it is in delayed state - so it is correct.

Now I'm eager to know these initial randseed values for cave E1 from BD2. Could anyone check this, please?

[subotai]

For PLCK Caves: $1E $00;
for Bd2 Cave E1: $E5 $21;

An element that passes the slime gets the falling state.

[cirix]

piter: i spent a lot of time on researching the slime predictability. i copy the relevant stuff here from the gdash source documentation (docs/c64_internals.txt).