In the course of writing articles for newsletters, one
sometimes wonders whether or not anyone out there is actually reading them. In the last month, I have had very little response to this column and absoultely ZERO input to the GFA BASIC SIG (message area number 20) on the ACE [NSW] BBS. To be honest, if we don't get any positive feedback soon, then I'll recommend we release the much needed disk space back to the Editor and Sysop for topics of more widespread interest to members. So if anyone out there wishes this GFA support to continue, let me know, O.K.?
You hear a lot about structured programming nowadays, and
perhaps it's time that someone (me, for instance) cleared out the cobwebs and put the issue in its proper perspective. First of all, what is it? Quite simply, it is a programming style which, when followed in a logical manner, will tend to make your programs more understandable and easier to debug and maintain. That's all there is to it. It won't make your programs faster or more user friendly, but it can help make YOUR life as the programmer a little less tiresome in the long run.
The first rule in structured programming is that there are no
rules. After all, it's YOUR program (discounting those of you who hack for a living, of course). What you can do though is to set up a few guidelines for yourself and try to follow them in each program that you write, hence establishing a sort of pattern. For example, here are a few guidelines that I TRY to follow:
1) Use a program header. I always include a program
header which consists of a bunch of remarks at the very top of my listing which identifies the program name, filename, date last revised, major modifications made, and a list of bugs that still need to be corrected.
2) Write your program like you are writing a story.
Have an "introduction" (initialization), "body" (main), and a "conclusion" (finish). Keep the main routine as short as possible by using procedures to do the dirty work. Put the main routine near the beginning of your program and arrange your procedures in a logical order, putting those less frequently used near the end.
3) Use one command/statement per line. Fortunately,
GFA BASIC pretty much forces this requirement on you by not
allowing concatenation of multiple commands on a single line.
Yes, this may make your program listings longer but also makes them SO-O-O-O-O much easier to read.
4) Use intuitive variable and procedure names. The
days of 8 character long variable names are long since past. GFA allows variable names of up to 256 characters in length, and these may consist of letters, numbers, underscores, etc. Why use "d=1.5" and "GOSUB gc" when "dollar_amount=1.5" and "GOSUB get_colors" are so much more understandable.
5) Be consistent in variable names. Use the same
variables as loop counters throughout your program, and establish a common rule for nameing integer, real, and boolean variables.
6) Minimize GOTO instructions. Note that I say
"minimize", not "eliminate". There are times when a GOTO instruction may, in fact, be not only appropriate but the most efficient way to handle an exit condition. Even so, GOTOs are notorious for making code hard to follow so do try to use them sparingly, if at all.
7) Make your code self documenting. Each procedure
should be relatively understandable when taken by itself. Make liberal use of comments (remarks) to clarify what each procedure or function does.
Remember, these are just some of MY guidelines. Develop a
programming style that is comfortable to YOU and stick to it. GFA BASIC is not near as restrictive as Pascal or Modula II but it has a lot of features to support structured programming so use them!
One of the most common tasks faced by ST programmers
(especially for games) is the loading of a DEGAS (.PI) format picture file. While there are many ways to accomplish this in GFA BASIC, what follows is a short standalone program with procedures I have found to work well for this task. The following example is for color files but monochrome works the same way.
' Use the following routine to load an uncompressed, 32K DEGAS
' picture file into GFA BASIC.
' Do this DIM statement only ONCE at the beginning of your program
DIM sa%(16) ! Array for DEGAS palette
' Your program goes here
' Set a$ to the DEGAS file you wish to load. Include proper path.
@get_degas ! GOSUB to the procedure
' The rest of your program goes here
CLS ! Clear the screen
HIDEM ! Turn the mouse off
' Optional "black-out" routine to turn off screen during loading
' FOR i%=0 TO 15
' SETCOLOR i%,0,0,0 ' NEXT i% BLOAD a$,XBIOS(2)-34 ! Load the picture a%=XBIOS(2)-32 FOR i%=0 TO 15 ! Read DEGAS colors sa%(i%)=DPEEK(a%) ADD a%,2 NEXT i% FOR i%=0 TO 15 ! Set the ST's colors a=XBIOS(7,i%,sa%(i%)) Next i% SHOWM ! Turn mouse back on RETURN '
Similarly, you may load NEOCHROME (*.NEO) format picture
files with this routine:
PROCEDURE get_neo BLOAD a$,XBIOS(2)-128 ! Load the file a%=XBIOS(2)-124 FOR i%=0 TO 15 ! Get the NEO colors sa%(i%)=DPEEK(i%) ADD a%,2 NEXT i% FOR i%=0 TO 15 ! Set the ST colors a=XBIOS(7,i%,sa%(i%)) NEXT i% RETURN '
In the above examples, the DEGAS or NEOCHROME format picture
files must match the screen current resolution. But what if your application runs in medium resolution but you wish to display a low resolution picture file (or vice versa). Try this routine:
res%=XBIOS(4) ! Get screen resolution
' If pix is medium & screen is low:
IF RIGHT$(a$,1)="2" AND res%<1
VOID XBIOS(5,L:-1,L:-1,W:1) ! switches to med res ELSE ' Or if pix is low & screen is medium: IF RIGHT$(a$,1)="1" AND res%>0
VOID XBIOS(5,L:-1,L:-1,W:0) ! switches to low res ENDIF RETURN
Note the use of the XBIOS(4) call. This simple function
returns the current screen resolution:
0 = Low resolution color 1 = Medium resolution color 2 = High resolution monochrome That's it for now. Stay tuned for more hints next time.
Your feedback is IMPORTANT! Send your comments, questions,
suggestions, hate mail, etc, to me via E-mail or the GFA SIG on
the ACE BBS.