The Magic wall Bug

Everything about the old and new Boulder Dash games for C64, Atari, ...

Moderator: Admin

Post Reply
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

The Magic wall Bug

Post by subotai »

I don't like this magic wall bug at all. Besides, I don't think that it has any relevance in existing games, maybe only the amoeba conversion part. That's why I'm not sure if I will implement it into my game.

You can be sure that I analyzed this bug carefully. However, you should check the following information for accuracy before implementing it.

Keep in mind that stones interact with the magic wall, not the magic wall with stones. When a falling stone drops into the magic wall, the following things will happen (go to step 2.)

Code: Select all

1. A falling stone drops into the magic wall
2. The scan is aborted directly without changing or resetting the delayed state of any element in the cave
3. The position of the field to the diagonally up/left will be saved
4. Only the delayed states of all elements above this saved position are reset (delayed state = false)
5. Now, the cave is rescanned from the beginning
6. If another stone drops into the magic wall, then go to step 2.
That's all. Now I will explain a little bit the different steps.

Code: Select all

=> 2) All the following elements are not scanned during this frame. If no amoeba was able to grow before, all amoebas will turn into diamonds in the next scan.
=> 3) Example: The falling stone that lies on the magic wall, before it drops into it, is located at position xy(5,5). The field to the diagonally up/left is at xy(4,4)
=> 4) The delayed state of the elements from xy(0,0) to xy(3,4) are set to "false/not delayed"
=> 5.) This is a normal scan. all the elements above the saved position (step 3.) can move again (delayed state = false)
Timing (What I can judge by sight)
During the rescan, the elements above the saved position (step 3.) move very quick. Sometimes you can't even see the drawing. The elements beyond the wall move nearly at normal speed, slowed down only a little bit.

My opinion is that the cave delay takes place after the scan routine. If the scan was aborted, the cave delay is performed after finishing the rescan, not before.
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Re: The Magic wall Bug

Post by LogicDeLuxe »

The speed increase is easily explained: Skipping the processing of the remaining elements saves CPU time, and since the next scan starts earlier, it appears faster as well. The higher the magicwall used is placed, the more the speed increase it is. Use a magic wall at the bottom, and you won't barely notice any increase. Place it close to the top, and it seems like speed of light.

Also, incidentally, this breakscan goes along with visual glitches, though this is another bug which can be fixed easily, without changing the behavior. This fix is part of my BD3 patch.
subotai wrote:Besides, I don't think that it has any relevance in existing games, maybe only the amoeba conversion part.
Not exactly. Even though, it is indeed rare, there are a few relying on it. Take a look at De Luxe Caves 1 Cave L, De Luxe Caves 2 Cave A or Deluxe Caves 3 Cave A for some examples. There are a few more from other authors.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

LogicDeLuxe wrote:The speed increase is easily explained: Skipping the processing of the remaining elements saves CPU time, and since the next scan starts earlier, it appears faster as well.
Yes, and you can also notice this in some intermissions, which are extremely fast.
LogicDeLuxe wrote:Take a look at De Luxe Caves 1 Cave L, De Luxe Caves 2 Cave A or Deluxe Caves 3 Cave A for some examples.
That's interesting. I will check these.
Post Reply