Rocks'n'Diamonds

Holger wrote:The reason is not your new harddisk, but that you have freshly installed Windows on your PC.

No, when I reinstalled windows with the old harddisk, it was absolutely slower. The writing and reading speed was slower! It was quite an old one, so there's absolutely difference. maybe not for rnd, but absolutely for the myst IV game.

OK, now on-topic again...

1. In files.c in setLevelInfoToDefaults code do next things:
level->block_delay = 8;
level->sp_block_delay = 9;
Later in LoadLevel_InitVersion code do this:
level->block_delay = (level->block_last_field ? 7 : 1);
level->sp_block_delay = (level->sp_block_last_field ? 7 : 1);
Maybe we need 8 instead of 7?

2. Setting level->sp_block_delay to 9 is a bad idea: in any level with MURPHY you can move 1 field left and quickly move to right and then quickly left and then quickly right and continue such type of moving do next: if there is a zonk over field he will never fall, while in Supaplex zonk falls at 2nd MURPHY leaving.

3. For Supaplex in game.c in StartMoving code should be next:
if (can_fall_any)
{
InitMovingField(x, y, can_fall_left ? MV_LEFT : MV_RIGHT);
started_moving = TRUE;
}
i.e. not can_fall_left = !(can_fall_right = RND(2));

Found a new bug (actually I found it in v3.1.1 but no matter). Magic wheels don't work in native EM levels.

> Found a new bug (actually I found it in v3.1.1 but no matter).

Please open a new thread for each newly detected bug -- thanks!

> Magic wheels don't work in native EM levels.

Well, they do -- go to the "properties" page and enter a "duration" value greater than zero...

But you are right that the default value "0" is a "bug" -- I'll change this...

Sorry DiPal -- I just found your post by chance; no idea why I did not see it before. :-(

> 1. In files.c in setLevelInfoToDefaults code do next things:
> level->block_delay = 8;
> level->sp_block_delay = 9;
> Later in LoadLevel_InitVersion code do this:
> level->block_delay = (level->block_last_field ? 7 : 1);
> level->sp_block_delay = (level->sp_block_last_field ? 7 : 1);
> Maybe we need 8 instead of 7?

Well, no, it's 7 and not 8 in previous versions, that's why it's 7 here (for downwards compatibility, as always). If I would rewrite it from scratch, it would indeed be 8, of course. :-)

> 2. Setting level->sp_block_delay to 9 is a bad idea: in any level with
> MURPHY you can move 1 field left and quickly move to right and then
> quickly left and then quickly right and continue such type of moving do
> next: if there is a zonk over field he will never fall, while in Supaplex zonk
> falls at 2nd MURPHY leaving.

This one is tricky; you definitely have a delay of 9 (and not 8 or 7) in original Supaplex when moving *down*, that's why I chose 9 here. Because I wanted to be generic here (there's currently only a "last field", not a "last field when moving [left | right | up | down]", so I used 9). Later I noticed that this can cause problems like you described above. :-( Not sure how to solve this at the moment... Maybe I should hardcode it for each direction differently... :-/

> 3. For Supaplex in game.c in StartMoving code should be next:
> if (can_fall_any)
> {
> InitMovingField(x, y, can_fall_left ? MV_LEFT : MV_RIGHT);
> started_moving = TRUE;
> }
> i.e. not can_fall_left = !(can_fall_right = RND(2));

You mean: Supaplex elements always prefer falling left, then right -- this should be corrected in the new version 3.1.1 (available since yesterday).