; Copyright 2014-2022, 2025 Richard Dymond (rjdymond@gmail.com)

[Bug:animatedPlatform:The animated platform]
There is a platform at (9,7) in #R62464(Amoebatrons' Revenge) whose third row
of pixels is animated as if it were a conveyor. This is because there is a
conveyor defined at that location (see #R63087), but the cavern layout places
regular platform tiles there instead of conveyor tiles.

#UDGTABLE { #CAVERN17,0,5,16,8,2(animated_platform) } TABLE#

To disable the animation (by moving the conveyor up a row to (8,7), which is
occupied by background tiles):

POKE #R63087(63088),7

See #FACT(unusedConveyors)() for more information.

[Bug:nineLivesInTheLight:Nine lives in the light]
The code that decreases the air supply when Willy is in the light beam in
#R63488(Solar Power Generator) doesn't check whether the air has run out, and
so depending on the remaining air supply at #R32956 and the game clock at
#R32957 when Willy enters the beam, he will not necessarily die when the air
runs out; instead the air supply is replenished a little and then depleted,
repeatedly up to eight times - until the game clock hits zero upon exiting the
beam-controlling routine at #R36211.

To see Willy survive eight air supply depletions, use the following POKEs:

<div>POKE #R33885(33885),7 - press keys 256 to teleport to the cavern</div>
<div>POKE #R36252(36252),24 - make the light beam pass through guardians</div>
<div>POKE #R64104(64104),208 - Willy's initial pixel y-coordinate * 2</div>
<div>POKE #R64108(64108),183: POKE 64109,93 - Willy's initial position</div>
<div>POKE #R64188(64188),39 - initial air supply</div>
<div>POKE #R64211(64211),255 - remove the yellow guardian at ground level</div>

[Bug:throughTheWall:Through the wall]
If Willy jumps left over the two nasties at the bottom right of
#R49152(Eugene's Lair) such that he lands on the top layer of bricks with
animation frame 3 at step 16 of the jumping animation, he will then fall
through them to the bottom layer of bricks:

#UDGTABLE(gallery)
{ #WILLY4,23,93,4,20,11,8,5(through_the_wall1) |
  #WILLY4,22,96,7,20,11,8,5(through_the_wall2) |
  #WILLY4,22,100,6,20,11,8,5(through_the_wall3) |
  #WILLY4,22,104,6,20,11,8,5(through_the_wall4) }
{ Step 15 | Step 16 | Step 17 | Step 18 }
TABLE#

This happens because the section of code at #R35600 - which is executed during
jumping animation step 16, after Willy's y-coordinate has been updated so that
he's exactly one cell height above the place he jumped from, but before his
x-coordinate has been updated - checks whether there are any nasty tiles in the
cells below Willy's sprite. If there are (as is the case here), the code jumps
forward to #R35665, which makes Willy proceed to the next jumping animation
step (as if the bricks were not there), instead of landing on the bricks.

Perhaps the assumption in this code is that if there is a nasty tile below
Willy's sprite in step 16, then he will be killed by the nasty before reaching
step 17; however, in this particular case Willy's x-coordinate decreases by one
during step 16 (as he transitions from animation frame 0 to frame 3), which
moves him out of the nasty's range.

[Bug:throughTheWallAgain:Through the wall again]
It's also possible to jump and land inside a wall block even when there is no
nasty next to it.

If Willy's animation frame is 0 at step 16 of the animation while Willy is
jumping left, the code at #R35996 checks whether Willy is free to move left
across a cell boundary. However, the part of that code that checks whether
there is a wall tile below Willy to the left is skipped when Willy's sprite is
cell-aligned (i.e. when his y-coordinate at #R32872 is a multiple of 16), which
is always the case at step 16. Consequently, Willy moves left across the cell
boundary and then, in step 17, he moves down into the wall block below before
any check is made for wall blocks beneath him, eventually landing with
animation frame 2.

Places where this can happen are:

#UDGTABLE(gallery)
{ #WILLY4,17,96,6,13,10,10,6(ttwa_el) |
  #WILLY15,17,56,6,13,5,10,6(ttwa_sc1) |
  #WILLY18,2,104,6,0,10,10,6(ttwa_spg) }
{ #R49152(Eugene's Lair) |
  #R60416(The Sixteenth Cavern) |
  #R63488(Solar Power Generator) }
TABLE#

Similarly, if Willy's animation frame is 3 at step 16 of the animation while
Willy is jumping right, the code at #R36054 checks whether Willy is free to
move right across a cell boundary. However, the part of that code that checks
whether there is a wall tile below Willy to the right is skipped when Willy's
sprite is cell-aligned (i.e. when his y-coordinate at #R32872 is a multiple of
16), which is always the case at step 16. Consequently, Willy moves right
across the cell boundary and then, in step 17, he moves down into the wall
block below before any check is made for wall blocks beneath him, eventually
landing with animation frame 1.

Places where this can happen are:

#UDGTABLE(gallery)
{ #WILLY0,16,56,1,12,5,10,6(ttwa_cc) |
  #WILLY1,27,32,1,22,2,10,6(ttwa_tcr) |
  #WILLY6,13,88,1,9,9,10,6(ttwa_tv) |
  #WILLY15,9,80,1,5,8,10,6(ttwa_sc2) }
{ #R45056(Central Cavern) |
  #R46080(The Cold Room) |
  #R51200(The Vat) |
  #R60416(The Sixteenth Cavern) }
TABLE#

When Willy lands inside a wall block, he can walk straight through it unless
another wall block is in the way.

[Bug:attributeCrash:Attribute crash]
When a Skylab in #R58368(Skylab Landing Bay) crashes into a section of floor or
conveyor, the attributes of that section are temporarily changed to that of the
Skylab; the attributes are restored after the Skylab has finished
disintegrating.

#UDGTABLE {
  #CFRAME13
  #COPY(14,8,8,5,2)(13,ac)
  #UDGARRAY(2,15,,2)(59200-59217-1-16;15616x2,,1)(*skylab)
  #OVER(3,1,0,0,1)($f)(ac,skylab)
  #FRAMES(ac)({ScreenshotImagePath}/attribute_crash)
} TABLE#

The reason for this is that the code at #R36447 (which is used to set the
attributes for a Skylab) sets the attributes in not two but three rows of
cells, to handle the case where a guardian's sprite is not cell-aligned.
However, when a Skylab crashes, it <em>is</em> cell-aligned, and so its
attributes needlessly bleed over to the floor or conveyor cells immediately
below it.

[Bug:blueShadow:Blue shadow]
As Willy enters #R63488(Solar Power Generator), the blue vertical guardian can
be seen casting a 'shadow' over the floor immediately below it.

#UDGTABLE { #CAVERN18,15,9,4,4(blue_shadow) } TABLE#

This happens for the same reason as a Skylab's colour bleeds over into the
floor below when it crashes - see #BUG(attributeCrash)(). This effect does not
occur on subsequent occasions when the guardian approaches the floor, because
it never actually touches the floor again - its maximum pixel y-coordinate is
79, one less than its original y-coordinate of 80 (see #FACT(outOfBounds)()).
