TIPS FOR THE TOP

by Gavin B Monk

from Your Spectrum 10 (Dec'84/Jan'85)



Contributions to Program Power have been arriving at a steady

rate over the Summer months and the quality has improved

considerably since my few suggestions in issue 3.

	What I'm doing this month is looking through all of the listings

we've published in YS so far, picking out the good bits, adding a

few little extras of my own - and presenting you with a series of

nine routines. The REM statements may, of course, be omitted,

but personally I'd suggest that you leave them in.

	The routines use lines 1-30 and lines 8000-9999 which should

still leave you plenty of room for your own program. They offer the

following facilities: flashy border, happy tune, UDG generator,

display lives, end of game/high score, string input editor, case

converter, user-defined keys and valid answer checker. You'll find

a good explanation of each routine as it's listed in the following

pages. The best thing to do is to type the whole program in and

then, using the annotations for each routine, play around with each

section until you understand how each one works.



Lines 1-6

Cause a jump past the 'flashy border' routine so that the

command RUN will still your program in motion.



Lines 7-20

This routine is placed at the start of the program to ensure it

runs fast and produces a steady display. Called by GO SUB

10, this routine will cause a spectrum of stripes to be

displayed across the top half of the border, while waiting for a

key press. When you leave the routine, the border colour will

revert to white. The PAUSE 1 statement matches the program

speed with the TV scan.



Lines 30-31

You've got lines 30-7996 to write your own program - all

you have to do is call the relevant routine you need to spice up

the proceedings.



Lines 7997-80160

Use the 'happy tune' routine when you want to give a reward

for good play ... perhaps to signal a new high score, extra

life or a switch to a new level. The routine produces an eight-

note tune from the data in line 8050. You can call it by GO SUB

8000; note that it uses the variables 'i', 't' and 'n'.



Lines 8097-8150

This routine provides a simple user-defined graphics

generator. First plan your UDG graphics, either on graph

paper or with a suitable software package, and then make a

note of the values as detailed in the Spectrum manual. Now

change the 'u' in line 8110 so that only the number of

graphics required will be set up - for instance, 'd' will allow

graphics a-d to be defined. Place the data for each character

in lines 8160-8180 and, to set up the UDGs, call the routine

with GO SUB 8100.



Lines 8159-8180

These lines have been set aside for you to allocate the data

you'll need to define each of the UDGs in your program.



Lines 8197-8210

String handling on the Spectrum is very different to that

found on all non-Sinclair impedimenta, but did you know that

items inside quotes in PRINT statements can also be sliced?

"What use is this?", I hear you wonder. Well, if you define a

UDG character to represent your playing character, then you

can quite easily have a string of characters displaying the

number of lives anywhere on the screen. Set 'x' and 'y' to

represent the co-ordinates of the screen position required

and let 'li' equal the number of lives. Now, call the routine

with GO SUB 8200 and you'll find that the remaining number

of lives will be printed up on-screen in the form of a row of

player characters - Pacmen, for example.



Lines 8297-8420

This very handy routine is all that's needed to convey the sad

message: "I'm sorry but your game is over". It also requires

the input string editor (see the next routine), the 'happy tune'

routine, and variables 'sc' (score) and 'hs' (high score) to be

set. The routine is called by GO SUB 8300, and on return from

the routine the high score name will be stored in h$. The

maximum name length is set to five characters in line 8400,

but this can be adjusted to suit.



Lines 8497-8690

If you've ever wanted to get rid of those keywords and

punctuation marks accepted by the INPUT statement, then

this one's for you. This input string editor allows screen line

21 to be used for alphabetical inputs of up to 32 characters.

The input is checked that it doesn't contain keywords and all

the other yuck that the normal INPUT accepts. The routine is

quite long and you must note that it uses a$ (stores input), k$

(stores the key pressed) and 'co' (code of the key pressed). It

all works by checking the code of the key pressed to see if it's

in the required range; it it's the Enter or Delete key, then the

appropriate jump is made to a routine which adds the key to

the entry, stops the input or deletes the key from the input.

This routine should be especially useful for adventure

programmers.



Lines 8697-8850

Here's another routine for the adventure freaks out there who

are worried about the Caps lock being switched on or off

during an entry. Everybody, of course, knows that POKE

23658,8/0 turns it on or off respectively. The trouble is, doing

this doesn't stop someone turning it off/on during a listing.

The answer is to change the limits in line 8590 of the input

routine above, or use this two-case converter routine. To

convert a$ to upper case use GO SUB 8700 - to lower case,

GO SUB 8800. Note that the variables used are 'i' and 'co'.



Lines 8897-9130

Many commercial games now have a user-defined key option

- the final solution for complaints about the control key

layout. But here, another hidden benefit is that the Interface 2

and AGF joystick protocols can be used. This routine returns

the keys selected in m$ (the movement string!) in the order

given in the data statement at line 9130. The first digit in this

statement is the number of keys required and the strings

following this detail the purpose of each; checks are made to

ensure the same key is not used twice. The following

variables are used by the routine; nk (number of keys

required); d$ (direction of required key); and k$ (key

pressed). The 'flashy border' routine is also used so that a

key press is waited for, once all the required keys have been

entered. To add this feature to your game just GO SUB 8900.

To check for movement in a game, all you now need is

something rather like this:

	IF INKEY$=m$(3) THEN ...: REM

	detects 'up' movement if using the given data



Lines 9497-9600

This routine checks for a valid answer, but to be quite honest

this is not so much a routine ... more a collection of hints.

Line 9500 asks for an answer to be input and this answer is

then taken in a$; lines 9510 and 9550 check it for length (up to

five characters) and invalid characters. If one of these is

found, a message is flashed up briefly on the input line - and

then the input prompt reappears once more. By changing the

limits in line 9530, checks can be made against numeric or

character inputs so that the VAL or VAL$ functions can be

used.





--

Another Fine Product transcribed by:

Jim Grimwood (jimg@globalnet.co.uk), Weardale, England

--