Bugs

Despite only having one line of code Rheolism has a few flaws. The number of bugs per line is quite large. So on top of being one of the shortest programs, is it the buggiest? Unfortunately, the answer is probably no.

Bug#0 Holding a key down will stop the brick dropping

In the key loop, the action is determined by using INKEY 6. The brick only drops when there is no key in the keyboard buffer. It's easy to stop the brick dropping at all by holding a key down.

Bug#1 A new brick is drawn without first checking it will fit

Because the first phase is undraw, a new brick will be drawn on the screen erasing any occupied at its start position. Usually this will go unnoticed because if there are any occupied square that near the top of the board the game may well soon finish anyway.

Bug#2 Number Too Big

ABSRND can sometimes be negative, in particular if RND returns -2147483648 (&80000000), ABS returns -(-2147483648) which in 32-bit two's complement is also -2147483648 (&80000000).

In this case b ends up with a value -2. This would cause program to stop with a "Number Too Big" error, when the action condition is evaluated

In practice this doesn't happen very often. There are 4294967296 different values RND can return and it only goes wrong for one of them. If it takes on average one second to play a brick, this will cause a problem on average once every 136 years of play.

Since the random number seed gets reset when the computer is switched on, the number of times it will go wrong in practice depends a lot on the position of the first problem value in the sequence. If this was early in the sequence, it may happen more frequently.

Bug#3 Pressing cursor keys

The cursor keys don't move the brick, and furthermore cause the text cursors to split and become visible on the screen.

Bug#4 "Number Too Big" when rotating

The variable i which stores the rotation can wrap around. Because of bug#0, the rotate key may be held down, preventing the brick from dropping. If the repeat rate is high and the key is held down for over a month the variable will wrap, and the code will fail.

The problem occurs because the variable is not reduced modulo 12 when it is updated.

Bug#5 Completed top line not removed

The game stops when a brick doesn't fall during play. In this case there is no test to see whether a line has been completed before stopping the game. This may seem unfair.

This is simply the way the logic of the program works. It might seem more natural to make the termination condition for the game that a new piece won't fit on the screen.


David Moore
$Id: bugs.html,v 1.4 2001/06/29 12:56:28 dsm Exp $