GFA BASIC TIPS By Frøystein Hustadnes (Antirip of the Unskilled)
This article concerns smooth movement in all directions of up to
150 lines of the screen in GFA-Basic. I will explain, line by
(almost) line how the MOVE.LST basic program works. The reason why
I saved it as a .LST file, is that I thought users of all versions
of GFA-Basic should have the oportunity to use it. Load it in
using the merge option.
Most programmers will use the commands Get and Put if they want
to move parts of the screen about. It works, but if one wants to
move more than 1/13 of the screen, they are too slow to avoid
flickering. To avoid flickering, you have to perform the movement
once each time the electron beam redraws the picture on your
monitor, that's 50 or 60 times a second on a colour monitor. And
you must avoid drawing where the electron beam is currently
fetching its data from. The Bmove and the Vsync commands comes in
very handy here.
But it sounds too good to be true, doesn't it? Well, O.K., there
are some draw-backs. It consumes a lot of memory, and it is very
difficult to put graphics "under" and on both sides of the
graphics to be moved. It is possible, but consumes quite some time
before you can actually put the graphics on screen, and has to be
"repeated" every 16 pixels. A simple, but slow way to do this, is
to use the fill command.
Before I start to explain how the program works, I will come with
the usual explanation of the low resolution screen memory of the
ST is built up. As you probably knew, the screen memory is 32000
bytes long in all resolutions. In low and medium resolution, there
are 200 lines. If you divide 32000 bytes by 200 lines, you'll
(hopefully) get 160 bytes per line. In low resolution, four words,
eight bytes, lie "on top of each other", and describe as a whole
16 pixels. Since one word is sixteen bits, there are four bits,
one nibble, per pixel. One nibble can describe 16 different
numbers, or here: colours.
It is pretty easy to move up to 3/4 of the screen one line down
or up. Put some graphics on the screen and try out the following
A%=Xbios(2) ! A%=Physbase. Explanation later on.
Bmove A%,A%+160,16000 ! Moves half of the screen one line.
Vsync ! Stabilizes the picture.
This small routine moves half of the screen memory, 16000 bytes,
one line, 160 bytes, downwards a time. But even Bmove is too slow
to move 32000 bytes 50 times a second.Read one of the latest
ST NEWS for an article about vertical scrolling.
One way to move part of the screen 16 pixels to the right, is to
move the screen memory eight bytesforwards. It works, but shakes
awfully. I sat playing with this one day, when an idea struck me.
If I had 16 copies of a graphic block, each one pixel to the right
of the previous, I could show them in a series, move 16 pixels to
the right and show them again. This would look as a soft movement.
Well, when I get an idea to solve a programming problem, it
doesn't take a long time before I'm sitting at my computer table
with my tongue halfway out of my mouth and one hand either on the
keyboard or in my hair (Then what about my other hand? It is
holding either a bottle or a glass containing l.. eh.. water.).
Before one starts to move the graphics about, one must make 16
copies of it, each one pixel to the right of the previous, and
place them in memory so that they are easy to collect. In this
example, I will move only 69 lines (My nurse says so. The
medicines I am given so that I won't start yelling "Pink Floyd!
Pink Floyd! Pink Floyd!" again makes me much too foggy to move any
more.). Every line is 160 bytes, and if one fetches the calculator
and types in 160*69, one will get the result 11040 bytes per copy.
And 11040 times 16 copies are 176000 bytes, just about maximum of
what you have to your disposal if you're using GFA 3.0 in a mere
520. (Hehehehe.. Guess how much memory my ST has?) The first
thing you have to do is to prepare memory, resolution and screen
memory. We'll let basic have 30 Kbytes.
In other words, this is the result you'll get when you type Print
Fre(0) with no basic program in memory.
We'll now find a suitable address to put screen memory in. This
has to be a number which gives an integer when divided by 256.
Himem is the highest address GFA Basic uses for variables, code,
etc. The next 5000 bytes is used by GEM for variables. But from
there on, everything is the programmers domain.
This sets the resolution and the bottom address of logical and
physical screen memory. Logical screen memory is where the
computer usually draws, and physical base is the base of the
screen memory which is displayed on your monitor. Usually, these
are alike, so that the user can for example watch while the
computer fills out shapes when using a drawing program. But if
logbase and physbase (Yeah, you guessed it; physical base of
screen memory.) are placed at different places in memory, the
programmer can let the user look at one screen while the computer
is drawing a screen at logbase, and then impress the user by
suddenly setting logbase and physbase to the same address. But if
you're using this in your own programs, remember that if one sets
the resolution, logical screen memory is blanked (Same as Cls.).
Use -1 as the last parameter of Xbios 5 to avoid this.
On break cont
Have you ever noticed that the speed of execution is drastically
reduced when you move the mouse? Anyway, it is. It's not so
drastically reduced if you hide the mouse, but it still is
reduced. To completely turn off the mouse, use Out 4,&H12 after
Hidem (Thanks, Ronny!). But it is of utmost importance to use Out
4,&H8 to turn on the mouse again before you end the program. This
is of course the reason why I made it impossible to break the
program the usual way.
O.K, we now have a blank screen with a lot of free bytes after
it. Let's put something onto the screen (We don't want to move
parts of a blank screen about, do we?)
For I=0 To Pi*2 Step 0.1
The graphics to be moved about is now placed on screen and copied
into A$. The work screen is placed right after the screen the user
is looking at. What we will do is to put the graphics contained in
A$ onto the top of the work screen, and then copy it to where it
belongs using bmove.
For I%=15 To 0 Step -1
That's it! We are finished with the preparations. The 'heart' of
the program will now follow.
Source%=Sc2%+11040*(X% Mod 16)
Exit If Inp?(2)
Inp?(2) returns zero if no key is pressed, otherwise, the usual
ASCII number is returned (A=65, space=32, etc.). If you cut out
the question mark, the program will wait until a key is pressed
(Thanks again, Ronny!).
It's not necessary to use two bmove lines. The reason why I did
it, is that I wanted to make the program a bit more impressive. I
think that you, being an experienced programmer(You are, aren't
you?), will manage to jerk out of the program its last secrets
yourself. That saves a lot of work for me, anyway. But I will
supply you with a hint before I'll jump into my much beloved bed:
Try to change the background colour (Setcolor 0,n) in between the
various commands to develop a sense of how much time a command
takes to execute. If this results in a terrible flickering, delete
one of the two bmove lines in the main loop.
I hope that I have been of help to you. Send any question/
suggestion/ donation to me:
If you feel that your telephone bill is a bit too small, call
(Norway) 070 50109.
If you have been treated badly by life, the politicians, Mrs.
Fortuna, the grocer, the market forces, the software houses, in
fact any thing/one, put your agression down on paper and send it
Gro Harlem Brundtland
Stortinget, Karl Johan
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.