Reading the Joystick

In the last unit a ball moved on a path you fixed in code, with Sin and Cos. A game doesn't work like that — the player decides where things go. So we throw the maths away and read the joystick instead. Blitz makes this beautifully direct: two functions, Joyx and Joyy, hand you the stick's direction as a plain number — push right and Joyx is +1, push left and it's -1, let go and it's 0. Add that number to a shape's position every frame and the player is steering. That's the moment a moving picture turns into a game.

What you'll see by the end

A single ball, gliding wherever it's pushed — right, then down, then back across and up. There's no path in the program this time. Every move you see is the joystick being read, frame by frame, and turned straight into movement. (Here the stick is driven by the capture; on your Amiga it's your hand.)

The whole program

; The player steers the ball with the joystick.
BLITZ
  BitMap 2,24,24,3
  Circle 12,12,11,6
  Circle 12,12,7,2
  GetaShape 0,0,0,24,24

  BitMap 0,320,256,3
  BitMap 1,320,256,3
  Slice 0,44,3

  x.w=148 : y.w=112
  db=0
  While Joyb(0)=0
    VWait
    Show db
    db=1-db
    Use BitMap db
    Cls 0
    If Joyx(1)=1 Then x=x+4
    If Joyx(1)=-1 Then x=x-4
    If Joyy(1)=1 Then y=y+4
    If Joyy(1)=-1 Then y=y-4
    If x<0 Then x=0
    If x>294 Then x=294
    If y<0 Then y=0
    If y>230 Then y=230
    Blit 0,x,y
  Wend

It's the bouncing-ball program from unit 8 with the Sin/Cos ripped out and the joystick wired in. The shape, the two pages, the flicker-free flip — all the same. Only how x and y change is new.

Reading the stick

If Joyx(1)=1 Then x=x+4
If Joyx(1)=-1 Then x=x-4
If Joyy(1)=1 Then y=y+4
If Joyy(1)=-1 Then y=y-4

This is the whole idea. Joyx(1) reads the left-right direction of the joystick in port 1, and gives you one of three numbers: 1 for right, -1 for left, 0 for centred. Joyy(1) does the same up and down: 1 for down, -1 for up, 0 for centred. So we ask four plain questions each frame — pushed right? pushed left? pushed down? pushed up? — and nudge x or y by 4 pixels for each one that's true. Centre the stick and all four are false, so the ball sits still.

The 1 in Joyx(1) is the port — the joystick socket, the one a game controller normally plugs into. (Port 0 is the mouse socket.) The fire button on that stick is Joyb, which you've been using all along as the quit test: While Joyb(0)=0 keeps the loop running until fire is pressed.

Diagonals come free

Notice there's no special code for diagonal movement, yet the ball moves diagonally just fine. That's because Joyx and Joyy are independent — push the stick down-and-right and Joyx(1) is 1 and Joyy(1) is 1, so x and y both change in the same frame. Eight directions out of four questions, for free.

Staying on screen

If x<0 Then x=0
If x>294 Then x=294
If y<0 Then y=0
If y>230 Then y=230

These keep the ball on the bitmap. The shape is 24 pixels wide, so the furthest right x can sit is 294 (294 + 24 is just inside the 320-wide screen), and 230 is the same idea downward. Without these clamps a determined player would push the shape off the edge — and a plain Blit off the bitmap is trouble, as you saw in unit 8.

What AMOS hides, Blitz hands you

On AMOS you'd ask separate questions — Jleft, Jright, Jup — each a yes/no. Blitz gives you the axis as a signed number: -1, 0 or +1, the direction and the sign in one read. That's a small thing, but it's the Blitz pattern again — you're handed the raw value the hardware reports, close to what the chips report, and you decide what to do with it. Multiply Joyx(1) straight into a speed, feed it to a lookup, test it against zero — it's a number, and it's yours.

Type it and compile it

Type the program into Ted and press right-Amiga + X (recompile if Blitz asks about memory). Push the stick and the ball follows; let go and it stops. Press fire to quit.

Try this: change the speed

The 4 in each line is the ball's speed, in pixels per frame. Change all four to 2 for slow, careful movement, or 8 for a fast dash. You can even make them different — a bigger number on x than y — for a shape that's quicker side to side than up and down.

Try this: momentum

Real game movement often has weight. Instead of moving x directly, keep a speed variable and let the stick change it: If Joyx(1)=1 Then sx=sx+1, then x=x+sx every frame, with a touch of sx=sx*9/10 to slow it. Now the ball builds up speed and coasts to a halt — the difference between a sprite and a spaceship.

If it doesn't work

• The ball won't move. Check you're reading port 1 (the joystick), not 0 (the mouse), and that the loop has a VWait so it runs once per frame.
• It moves but won't stop, or drifts. Each test must be exact: Joyx(1)=1 and Joyx(1)=-1. Centred, the stick reads 0, which matches neither — so the ball should sit still. If it drifts, you've likely tested Joyx(1)>0 against something unexpected; stick to =1 and =-1.
• The ball vanishes at an edge. The clamps must run every frame, after the moves and before the Blit. A Blit off the bitmap leaves the shape stuck or worse.

What you've learnt

Reading the joystick in Blitz is two functions: Joyx(port) and Joyy(port), each returning -1, 0 or +1 for the stick's direction on one axis, plus Joyb(port) for fire. Add those numbers to a shape's position each frame and the player is steering; because the axes are independent, diagonals come free; and a handful of clamps keep the shape on screen. That's player control — the piece that turns everything you've built into something somebody can play.

What's next

Your shape goes where it's told, but it's still a single still picture sliding about. Next — Animating a Shape — you'll give it life, cycling through several shapes as it moves so it walks, spins or pulses instead of gliding stiffly.