**See also:** part 1, part 2, part 3, part 4 and part 5.

## Math is hard, but some is easier.

Since it seems we might be needing math to move the ball around, let’s revisit some benchmarks on math to see which is faster. Using my BENCH.BAS program:

0 REM BENCH.BAS 5 DIM TE,TM,B,A,TT 10 FORA=0TO3:TIMER=0:TM=TIMER 20 FORB=0TO1000 70 NEXT 80 TE=TIMER-TM:PRINTA,TE 90 TT=TT+TE:NEXT:PRINTTT/A:END

…let’s declare a temporary variable, and then see how fast it is to add different values.

6 Z=0 30 Z=Z+1

Adding decimal 1 gives us about **280**.

Changing that to hex 1 (Z=Z+&H1) is basically the same.

BUT, adding 1 would just be moving on byte to the right. If we were moving down and to the right, that would be adding 33.

Z=Z+33 produces **355**. It’s having to do much more work to convert two decimal digits.

Changing that to Z=Z+&H21 results in **278**. It seems adding two hex digits is faster than adding one decimal digit :-)

Obviously, any math we want to do should be done using hex. But what math do we need?

Let’s start with a simple example that tries to “bounce” a single character around the screen.

## Bounce this

As a kid, I would do this with an X and Y, which I would then convert to a screen position like this:

PRINT@X+Y*32,"*";

I would then use variables for “X Movement” (XM) and “Y Movement” (YM) and add them to X and Y each time:

X=X+XM:IF X<1 OR X>30 THEN XM=-XM Y=Y+YM:IF Y<1 OR Y>14 THEN YM=-YM

There are problems with this approach (like, when it hits the bottom right of the screen, it scrolls up, and I’m also not erasing the “*”), but it’s good enough for a benchmark test:

6 X=0:Y=0:XM=1:YM=1 30 PRINT@X+Y*32,"*"; 31 X=X+XM:IFX<1ORX>30THENXM=-XM 32 Y=Y+YM:IFY<1ORY>14THENYM=-YM

This produces **2047**. If we change all the values to hex:

6 X=0:Y=0:XM=1:YM=1 30 PRINT@X+Y*&H20,"*"; 31 X=X+XM:IFX<&H1ORX>&H1E THENXM=-XM 32 Y=Y+YM:IFY<&H1ORY>&HE THENYM=-YM

Note I had to add spaces after the &H1E and &HE since BASIC can’t tell that’s the end of a value before parsing the next keyword (“THEN”).

This one change improves the speed to **1842**. A better way would be to eliminate the X and Y conversion completely, and just track one position (say, the top left corner). But without an X and Y, how do you know when you’ve hit the edge?

Since this is a demo, perhaps we don’t have to.

To be continued…