ROM Computer Magazine Archive ROM MAGAZINE ISSUE 5 — APRIL/MAY 1984 / PAGE 38

BEGINNER'S LINE CHARACTER GRAPHICS-PART IV
By GEOFF CORRY

    Well here we are again, in a new year and for some of you, a new computer. This is the last in the series on Character Graphics. This series started in Issue 2 of ROM, and I have noticed some back issues in some stores around the lower mainland; try your local drug store. If you can't find some back issues then we have some available at $2.50 per copy, which includes mailing. Leave a voice message at (604) 462 4177, or write to us, enclosing your payment, to ROM BOX 252, Maple Ridge B.C. V2X 761, and we will mail them out to you,

    This issue we will start a project that will take us on to character animation, screen flipping, scrolling and other programming techniques that the Atari carries out so well.

    Two small but important BOO BOO's crept into the short program on page 7 of the last issue. Lines 510 and 530 should be as follows:

  510 DATA 0,224,252,252,255,254,248,240
    
  530 DATA 240,248,252,254,255,252,224,0

    This should make 'an old friend' more recognizable.

    The name of the publication was omitted from one of the Font programs listed near the top of Page 8. The series on COMPUTER ANIMATION is in The Atari Connection, starting in the Spring '83 edition, and continuing. Some computer stores have a counter copy of this magazine for you to look at, or you may want to subscribe at $10/year for this useful publication, aimed at the new Atari owner. Another address for you;- Subscriptions, c/o ATARI CONNECTION, P.O. Box 50047, San Jose, California, U.S.A. 95150.

    Now that's over, lets get on with character graphics. I am going to describe how to layout shapes using the modified character set to form larger picture elements on the screen. Then we will introduce the project that will include character graphics, as well as other dynamic programming features for your Atari.
    In the Christmas greeting program in Issue 4, the trees that were 'planted' to form 'Merry Christmas', were each created by altering the lower case letter 'o'. It looked a bit lopsided, so 1 added one more pixel on the right, using a modified 'p' character.
    We used another trick to get more color on the GR. 0 screen by a process called artifacting. The trick uses odd or even columns to locate the pixels.

    The green color comes from using only columns 1,3,5,& 7. The holly berries used only columns 2,4,6,& 8 to give the red color. This happens because this fine vertical line only illuminates the green or red phosphors on your color T.V. By shifting the vertical pattern one pixel width either right or left gives you a green or red overall color. Here is a 16 by 8 grid to show you how the trees are formed:

         ___________GREEN_____________
         V   V   V   V   V   V   V   V
           ____________RED______________
           V   V   V   V   V   V   V   V
     /  ---------------------------------    \
    |  8| | | | |X| | | | | | | | | | | |  0 |
    |   ---------------------------------    |
    |  8| | | | |X| | | | | | | | | | | |  0 |
    |   ---------------------------------    |
 SEE|  8| | | | |X| | | | | | | | | | | |  0 | SEE
    |   ---------------------------------    |
LINE| 42| | |X| |X| |X| | | | | | | | | |  0 |LINE
    |   ---------------------------------    |
 640| 42| | |X| |X| |X| | | | | | | | | |  0 | 650
    |   ---------------------------------    |
    |170|X| |X| |X| |X| |X| | | | | | | | 128|
    |   ---------------------------------    |
    | 12| | | | |X|X| | | | | | | | | | |  0 |
    |   ---------------------------------    |
    | 12| | | | |X|X| | | | | | | | | | |  0 |
     \  ---------------------------------    /
         1 6 3 1 8 4 2 1 1 6 3 1 8 4 2 1
         2 4 2 6         2 4 2 6
         8               8
         \__modified ___/\__modified___/
            letter 'o'     letter 'p'

    The short trunk in the bottom two rows use two adjacent pixels (code 12 in line 640) which take on the brown color against the white background, The background is controlled by Color Register 2 in Gr.0 Mode (SETCOLOR 2;11,10 in line 100). The holly leaves and berries took the most time to set up and they used up 14 characters, 'a' to 'n'. Take my word for it, spikey holly leaves are tough.

-- GOING TO TOWN PROJECT --

    Now for the new project. Just to set the stage, lets imagine you live on a farm, some distance from the town where you, and your family, do your shopping. You have decided to pick up some things in town, and your appointment with the dentist has just come up. First you get in your car. All you can see is the back inside wall of the garage (character graphics), you look behind you, out the rear window (page flipping). Rack out slowly, you don't want to flatten any chickens that are wandering about. You turn (horizontal scrolling). Oh Boy! You you turned in the wrong direction, look forward (page flip) and turn back: into the garage. Careful don't hit the door posts (P/M graphics, collision registers). O.K. Back out and turn the other way. What's that squark ? (sound effects). Looks like you will have to buy another chick to replace the one you squished. Now drive to the gate and stop.
    Time to check the list. Hit 'L' (keyboard handler), you see the shopping list displayed. There are groceries, feed for the hens, parts for the tractor that broke down today, and one chick. Also there are books to return to the library and a dentist appointment at 2:P.M, Lets see how much money we have. Hit 'W' for wallet. The amount of cash you are carrying is displayed as well as your bank password number and checking account balance. Looks like we don't have enough, so better go to the bank first. (While we are checking the list, the next part of the program is loading.)
    This section will look down on a view of the roads around your farm and will scroll when you drive along the road (character graphics, scrolling, and player missile graphics). Finally when you see the freeway, you drive to the intersection before the freeway access. The scene changes, you are now back in the car, looking ahead. There is a red traffic signal (we will give a short demo of this) which remains red until the freeway portion of the program loads.
    The light turns green and we enter the freeway access. You hear a beep, somebody wants by. You steer into the right lane and let him pass. Oh,oh, there's a accident up ahead, better slow down. Finally you can see the sign showing the turnoff to the town. Drive off the freeway exit and wait at the traffic signal. While we are waiting, the town portion of the program loads. The map of the town is displayed, again use the joystick to control the two way scrolling. We can now check all the locations that we have to go to. First, drive to a car park that's convenient.
    Now we are walking to the bank. They have one of those automatic tellers. Follow the directions as they come up. We enter our password-- remember, the one we saw when we checked how much money we had, We key in the amount we want to withdraw. Now we can check our wallet again for the amount we now have and also our new bank balance. Hit 'T' for time, it's almost two o'clock. better find the dentist's office. (Some nice dentist noises would come about now. Brrrr.) After that's over, we can continue with the shopping. Don't forget the chick. Then back to the car park. Pay for the parking, and then drive back to the farm.
    
Now this kind of game would be 'booooring' if there wasn't some variety in what goes on. We will access a data file from time to time, and pick at random some of the suitable things to do or see. Maybe the tractor is in front of the garage when we want to drive out. The list of things to get and appointments to keep would change each time the game is played. We may have to detour along another road because a bridge is washed out. It's up to our imagination, system capabilities, and time factors, how this works out, I welcome your suggestions, and as we get along with this feel free to try out some of your ideas. Call us at the number at the beginning of this article.

    Charles Brannon, Program Editor for COMPUTE! magazine (Feb. '84) gives the following requirements for a good game:

    Selling Power (hope it keeps your interest up, and make you a regular reader of ROM).
    Style - things should happen in a reasonable way and also be creative.
    Telling Tales - this game will tell a different story,each time it is run, in the context of 'a trip to town'.
    More Depth - innovative ways to operate the various episodes that happen in the game.
    Using Capabilities - The Atari has great graphic abilities that can be used in so many ways.
    Finding A Center - Using graphics and sound to guide the way that the game develops during play.
    Playability - Each episode operates in a different way, and must be challanging but not confusing.
    Sound Effects - The car motor, the chick squark, sirens on the freeway, music from the record store, etc. to add realism to the game.

    We will keep these points in mind as we develop the various modules in this tutorial/game. An added interest will be the different techniques that we will need to find out and use as the situations come up. At this time (Feb. 1984) this game does not exist, but we will build it through this series of articles. You will get a chance to add or modify some parts to form your own version.

    Here is a small segment. The traffic signals before the freeway access and at the entrance into town will use ideas that we have already met in in the series on character graphics, Highway traffic signals have large borders around them to make them more visable. Our signal in this demonstration will be 4 characters wide and 10 characters long. The supporting pole will extend down the side of the screen. Here is the short program to try out. First we will use the familiar character move routine to get our characters down into an area of memory where we can change them:

10 RAMTOP=106:CHBAS=756:CHORG=57344
20 GRAPHICS 0:POKE 752,1:SE. 1,0,0: SE. 2,0,10:REM See next paragraph
30 RAMNEW=PEEK(RAMTOP)-8
40 START=RAMNEW*256
45 IF PEEK(START+1022)=16 THEN 80:REM Check to see if we have already moved it down. Why wait each time we run it
50 FOR CH=0 TO 1023
60 POKE START+CH,PEEK(CHORG+CH)
70 NEXT CH
80 POKE CHBAS,RAMNEW

    Here's a trick to save you time. These lines are mainly the same as the first few lines of last issue's 'Greeting' program, but we don't need the rest of the listing. If you 'saved' this program, 'load' it again and write down the counter number on your recorder. Now type in the following:
    LIST 20

Now add the setcolor statements in line 20 as shown above. We will then save lines 10 to 80 as follows:-
    LIST"C:",10,80

Press RECORD and PLAY on your recorder, and hit RETURN twice. For you disk drivers, type in:-
    LIST"MIGNAL.ROM",10,80

and hit RETURN.

    This will copy up to line 80 only (less the REM statements) onto your tape or disk. Now type 'NEW' and hit RETURN to clear the memory in your computer. Now rewind your tape and type:-
    ENTER"C:".

Press PLAY and hit RETURN twice. Diskers, type:-
    ENTER "D:SIGNAL.ROM"

and hit RETURN.
    This is a good procedure to use, when you want to select any group of lines from an existing BASIC program to use in a new program.

    To save memory space, something that will be very important as we get on with this project, we are going to show you two ways to put the shape information into a program. The first way is the procedure we used in the 'greeting' program, with POSITION statements followed by the actual converted characters in their relative positions. Please type this in:

100 FOR I=0 TO 135:READ A
110 POKE(START+197*8)+I),A
120 NEXT I
130 POS. 19,04:? "aaaabbbbcd"
140 POS. 19,05:? "afga     e"
150 POS. 19,06:? "ahia     e"
160 POS. 19,07:? "aaaa     e"
170 POS. 19,08:? "aaaa     e"
180 POS. 19,09:7 "aaaa     e"
190 POS. 19,10:? "aaaa     e"
200 POS. 19,11:? "aaaa     e"
210 POS. 19,12:? "         e"
220 POS. 19,13:? "         e"
230 POS. 19,14:? "         e"
240 POS. 19,15:? "         a"
250 POS. 19,16:? "         a"
260 POS. 19,17:? "         a"
270 POS. 19,18:? "         a"
280 POS. 19,19:? "         a"
290 POS. 19,20:? "         a"

    To make things clearer, the 'a's are converted to a black square, the 'b's form a horizontal black line, which is the support arm. The 'c's and 'd's form the bend in the pole, which is made up by the 'e's. We make the pole thicker by substituting 'a's in lines 240 to 290. Letters 'f,g,h, and i' make up the red light. (Artifacting -- remember?) Lets go on:

300 IF PEEK(764)=61 THEN GOSUB 440:? FRE(0)
310 IF PEEK(764)=62 THEN GOSUB 330:GO SUB 390:GOSUB 330:GOSUB 340
320 POKE 764,255:GOTO 300
330 FOR W=1 to 1000:NEXT W:RETURN
340 POS. 19,7:? "aaaa"
350 POS. 19,8:? "aaaa"
360 POS. 19,9:? "afga"
370 POS. 19,10:? "ahia"
380 POKE 764,255:RETURN
390 POs. 19,9:? "aaaa"
400 POS. 19,10:? "aaaa"
410 POS. 19,7:? "anoa"
420 POS. 19,8:? "apga"
430 POKE 764,255:RETURN
440 POS. 19,5:? "aaaa"
450 POS. 19,6:? "aaaa"
460 POS. 19,9:? "ajka"
470 POS. 19,10:? "alma"
480 POKE 764,255:RETURN

    These lines operate the lights. Lines 300 and 310 check the keyboard, waiting for you to either press a 'G' for GO, or an 'S' for STOP. Here's something to add a bit of confusion. Remember we talked about ASCII coding for the characters, and ATASCII code, which is Atari's version to include the graphic shapes, Then we went on to talk about internal coding,, which is ATASCII coding rearranged in blocks of 32 characters, so that the alphanumeric characters are all together for the larger print styles (Graphics 1 and 2),
    Now when you look at the keyboard, you can see that the letters are not arranged in alphabetic order. When you press a key, you are making contact at one of the crosspoints of the four rows and 14 columns. Memory location 764 holds the code for the last key pressed, and this code directly relates to the way that those contacts are wired out on your keyboard, The January '84 issue of A.N.A.L.O.G (page 103) has a complete table of the ATASCII, internal, and keycode numbers for all the 128 characters and special keys on your computer. We also listed out most of these keycodes on page 16 of Issue 1, if you have it.
    Now the code for 'g' is 61 and the code for 's' is 62. Due to the literal way this code is read, it is not necessary to go to the lower case (CAPS LOWR) to get this to work in our program. Here is a four liner you can use to see the code for any key pressed:

1 OPEN #1,4,0,"K:"
2 CODE=PEEK(764):IF CODE=255 THEN 2
3 GET #1,R:FOR W=1 TO 250:NEXT W:? " THE CODE FOR ";CHR$(R);" IS ";CODE
4 GOTO 2
    Type this in later (don't mix it with our program) and press CTRL CLEAR and then type RUN.

    I seem to get sidetracked, so lets go back to the main program. All those GOSUB's in lines 300 and 310 go to the subroutines that print over lights to switch them off, and then print another light either above or below.
    The one line subroutine, line 330, provides a 4 second delay when the light changes from green, through amber, to red. The poke 764,255 resets the keyboard handler, when the keys are pressed.
    Now lets end this program with the data statements that modify the characters:-

500 DATA 255,255,255,255,255,255,255,255:REM 'a' is changed to a black square for the light border and pole base.(Don't type in these remark statements).
510 DATA 255,255,0,0,0,0,0,0:REM 'b' is changed to a thick horizontal line to make up the signal arm.
520 DATA 252,255,3,0,0,0,0,0
530 DATA 0,0,192,224,112,56,24,24:REM 'c' and 'd' form the curve in the arm to the pole.
540 DATA 24,24,24,24,24,24,24,24:REM 'e' is the thick vertical line which makes up the pole.
550 DATA 253,245,245,213,213,85,85,85
560 DATA 95,95,87,87,85,85,85,85
570 DATA 85,85,85,213,213,245,245,253
580 DATA 85,85,85,85,87,87,95,95
    These 4 lines make up the red light, top left, top right, bottom left, & bottom right respectively. These are one pixel vertical lines with one pixel separation in, the round area of the red light.

590 DATA 255,250,234,234,170,170,170,170
600 DATA 255,191,175,175,171,171,171,171
610 DATA 170,170,170,170,234,234,250,255
620 DATA 171,171,171,171,175,175,191,255
    These four lines make up the green light in the same way that the red light is formed, except the vertical lines are moved over one pixel width.

630 DATA 255,249,249,249,153,153,153,153
640 DATA 255,159,159,159,153,153,153,153
650 DATA 153,153,153,153,249,249,249,255
660 DATA 153,153,153,153,159,159,159,255
    These four lines form the amber light. The artifacting does not work too well for this small area. The yellow effect is obtained by having vertical bars, two pixels wide, with one pixel separation.(Move the pattern over one pixel width and the color would be light blue).

    Now you have typed in this program, rewind your recorder back to the counter number you wrote down earlier, and CSAVE it (SAVE"D:SIGNAL.ROM for you diskers), and then RUN it. If everything is O.K., the screen should turn white, and after a few moments, the traffic signal will appear with the red light on. To change the light, press the 'G' key for a count of three. Pressing the 'S' key for a count of three will cause the light to change back, through amber, to red.
    When you push the 'G' button, you will notice some numbers come up on the left. This is provided courtesy of the 'FRE(0)' statement in line 300, and shows how much free memory is left in your system. When have jotted down this number, type 'NEW' and RETURN to clear this program. Type:- ? FRE(0) and RETURN and you will see the total memory available. Subtract the number that came up in the program to see how much memory your program took. This version took approximately 2340 bytes.
    LOAD the program back in. Type in the following lines as an alternate way to program this traffic light demo, using strings. According to all accounts, the use of strings to store information saves memory space. This is one of the criteria for the development of the 'going shopping' project. Here are some lines that will replace existing lines:

130 F=4:DIM LIGHT$(30),ARM$(10),BORDER$(F),POLE$(1),BASE$(1)
140 RED1$(F),RED2$(F),AMBER1$(F),AMBER2$(F),GREEN1$(F),GREEN2$(F)
    The length of all strings must be dimensioned with ATARI basic. A little trick to save some memory was used here. All the colors and the border used 4 characters (see lines 340-370 in the original program). Using the variable 'F' seven times. instead of repeating the '4', saves 6 bytes in the DIM statements.

150 LIGHT$="aaaabbbbcdeafgahiajkalmanoapga"
    You can see all the sets of characters used in the last program embedded in this 30 character string

160 ARM$=LIGHTS(1,10):BDRDER$=LIGHT$ (1,4):POLE$=LIGHT$(11,11):BASE$=LIGHT$(1,1):RED1$=LIGHT$(12,15)
    'ARM$' is the same character format in the first program (line 130), as well as being the first 10 characters in 'LIGHT$'.

170 RED2$=LIGHT$(15,18):AMBER1$=LIGHT$(24,27):AMBER2$=LIGHT$(27,30):GREEN1$=LIGHT$(18,21);GREEN2$=LIGHT$(21,24)
    Here are all the characters in lines 360,370,410,420,460,and 470 in the original program. Now to place them on the screen:

180 POS. 19,4:? ARM$ POS. 19,5:? RED1 $:POS. 19,6:? RED2$
190 FOR X=7 TO 11:POS. 19,X:? BORDER$ :NEXT X:REM Light assembly and arm.
200 FOR X=5 TO l4:POS. 28,X:? POLE$: NEXT X:REM Build the pole
210 FOR X=15 TO 20:POS, 28,X:? BASE$ :NEXT X:REM Assemble the base

    We don't need lines 220 to 290 in the original program but we will deal with that later. Lines 300 to 330,380,430, and 480 to 660 are the same in both programs, so why retype them.

340 POS. 19,1:? BORDER$
350 POS. 19,8:? BORDER$
360 POS. 19,5:? RED1$
370 POS. 19,6:? RED2$
390 POS. 19,9:? BORDER$
400 POS. 19,10:? BORDER$
410 POS. 19,7:? AMBER1$
420 POS. 19,8:? AMBER2$

440 POS. 19,5:? BORDER$
450 POS. 19,6:? BORDER$
460 POS. 19,9:? GREENl$
470 POS. 19,10:? GREEN2$

    Whew!! That's it.
    Now, two more things before we run it. There are some lines we don't need in this new version. Type 220 to 290 with a RETURN after each number. 'LIST 200,300' to make sure lines 220 to 290 have gone. Lets ' CSAVE ' or ' SAVE"D:SIGNAL.STR" ' before there is a power failure, or the dog chews up your T.V. cord. (Result-'Digital Dog' ). Hey, good name for a program!

    O.K. 'RUN' it. Hope it is the same as last time. It should be, except the number will be different. Strange, this number is larger than the last one by about 80 bytes. So much for using strings to save memory. Hold on, before you write me a nasty letter for putting you to so much work. We did learn a new method, and if our screen was loaded with character graphics instead of just one little old traffic. signal, we would have saved memory as well as writing a more compact program.

    That's it for now. Next time we will delve into display lists and horizontal scrolling; after all, we have to get that car out of the garage without running over any chicks.