pre-3.2.0-rc2

Found a bug in R'n'D? Report it here!

Moderators: Flumminator, Zomis

User avatar
Martijn
Posts: 794
Joined: Sat Jun 19, 2004 10:54 am
Location: the Netherlands (Holland)
Contact:

Post by Martijn »

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... ;-)
Visit my Boulder Dash website at:
http://www.bd-fans.com

Watch my avatar! That orange little thing is Murphy, the Supaplex star!
DiPal
Posts: 22
Joined: Tue Jun 22, 2004 8:45 am
Location: Belarus, Minsk

Post by DiPal »

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));
User avatar
Martijn
Posts: 794
Joined: Sat Jun 19, 2004 10:54 am
Location: the Netherlands (Holland)
Contact:

Post by Martijn »

Found a new bug (actually I found it in v3.1.1 but no matter). Magic wheels don't work in native EM levels.
Visit my Boulder Dash website at:
http://www.bd-fans.com

Watch my avatar! That orange little thing is Murphy, the Supaplex star!
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> 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...
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

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).
Post Reply