Using GFA BASIC - Part 02

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.?


STRUCTURED PROGRAMMING
----------------------
     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.

' GETDEGAS
' 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.
a$="A:FILENAME.PI1"
@get_degas                              ! GOSUB to the procedure
'
' The rest of your program goes here
'
END
'
PROCEDURE get_degas
  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
'

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:

PROCEDURE switch_res
  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.


HELP!!!
-------
     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.