Tennis

Tennis simulates a two-player tennis rally viewed in perspective, drawing a court and animating a ball traveling in a sine-wave arc between two players. The court geometry is rendered using PLOT and DRAW commands to create a three-dimensional perspective effect, including net posts and baseline markers. Eight user-defined graphics (UDGs A–H) are loaded via a DATA/POKE loop at initialization, defining the player figures in two animation frames each. Ball trajectory height and speed are randomized after each exchange using RND, and each player character shifts left or right depending on the ball’s arc height, providing a rudimentary AI movement system controlled by threshold comparisons on the sine-wave amplitude variables.

Program Structure

The program divides into four logical sections. Lines 10–15 initialize all variables. Lines 20–43 draw the tennis court using PLOT and DRAW. The main game loop runs from line 44 onward, with line 90 sending execution back to line 50. The subroutine at line 9000 loads eight UDG characters from DATA statements at lines 9010–9040.

Court Rendering

Lines 20–42 construct a perspective court entirely with PLOT and DRAW. Line 20 draws a series of short vertical segments stepping across the screen to suggest a back fence or crowd. Line 30 draws diagonal lines for the net posts. Lines 40–42 trace the court outline and service boxes using connected DRAW commands, giving a convincing three-quarter perspective view without any fill routines.

UDG Initialization

The subroutine at line 9000 uses a nested FOR loop to POKE 8 bytes into the UDG area for each of 8 characters (UDGs A–H, at USR CHR$ (143+f) for f 1 to 8). The 64 bytes are spread across DATA lines 9010–9040, each line holding 16 values. UDGs A/B and E/F represent the left player in two animation frames; UDGs C/D and G/H represent the right player similarly.

Ball Animation via Sine Arcs

Ball travel from left to right is handled in lines 50–60. The ball is plotted at coordinates (n, 50 + hl * SIN(n/235 * PI)) where hl controls arc height and sl controls step size (speed). The previous position is erased with PLOT OVER 1 before the next point is drawn, giving smooth pixel-by-pixel motion. The return journey (lines 70–80) uses hr and sr with a slightly different arc formula (n/255 * PI) so the two directions look distinct. After each rally, hl, hr, sl, and sr are re-randomized at lines 65 and 85.

Player Animation and Movement

Each player is drawn as a two-row UDG pair (e.g. AT a,b and AT a+1,b). When the ball is near the receiving end, the program switches to an alternate UDG pair (swing frame) for a brief PAUSE, then restores the standing frame, simulating a return stroke. Lines 57 and 59 move the right player one column left or right depending on whether hl (arc height) is below or above threshold values (65 and 72 respectively), controlled by flag variable t. Lines 77 and 79 do the same for the left player using hr, thresholds 73 and 85, and flag v. This gives a simple AI repositioning based on the incoming ball’s trajectory.

Key Variables

Variable	Role
hl	Arc height for left-to-right ball travel
hr	Arc height for right-to-left ball travel
sl	Step size (speed) for left-to-right travel
sr	Step size (speed) for right-to-left travel
a, b	Row and column of left player
c, d	Row and column of right player
t	Flag preventing repeated column shifts for right player
v	Flag preventing repeated column shifts for left player

Notable Techniques

• Using PLOT OVER 1 to erase the previous ball pixel rather than redrawing the whole screen, keeping animation smooth within BASIC.
• Two different divisors (235 vs. 255) in the sine argument alter arc shape for each direction of travel.
• Redrawing partial court lines at lines 83 and 87 restores segments that the ball pixel may have corrupted during transit.
• Short BEEP .01,0 calls provide a click sound at each stroke without interrupting the visual flow.
• PAUSE 5 after each stroke gives a brief freeze that makes the hit visually readable.

Anomalies and Observations

The variable names a, b, c, d, f, and g are reused in the UDG setup subroutine at line 9000, which overwrites the player-position variables initialized in line 15. The subroutine is called only once at startup (line 10) before the player positions are set in line 15, so this does not cause a bug in practice, but it is a tight ordering dependency. Lines 83 and 87 repair specific court segments that are likely to be hit by the ball but do not repair all potentially affected pixels, meaning prolonged play could degrade other court lines.