Page 1 of 1

The Magic wall Bug

Posted: Wed Mar 24, 2010 1:01 pm
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.

Re: The Magic wall Bug

Posted: Wed Mar 24, 2010 1:54 pm
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.

Posted: Thu Mar 25, 2010 4:27 pm
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.