IS ANYONE OUT THERE???
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!
LOADING GRAPHICS SCREENS INTO GFA BASIC
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
FOR i%=0 TO 15 ! Read DEGAS colors
FOR i%=0 TO 15 ! Set the ST's colors
SHOWM ! Turn mouse back on
Similarly, you may load NEOCHROME (*.NEO) format picture
files with this routine:
BLOAD a$,XBIOS(2)-128 ! Load the file
FOR i%=0 TO 15 ! Get the NEO colors
FOR i%=0 TO 15 ! Set the ST colors
CHANGING SCREEN RESOLUTION ON THE FLY...
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
' 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
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.