One thing that helps a games programmer more than
anything else is sprite capability and the ST is endowed with
sixteen bit square sprites in the same resolution as that chosen for
the screen and with any two colours of that available to the screen,
i.e. any two colours out of the sixteen available for low resolution
of 320 x 200 and any two colours out of the four available for
medium resolution of 640 x 200. You could mix sprites to give more
colours per sixteen bits square and many more things but so as not
to confuse I will endeavour to show the rudiments and leave the
talented stuff to you.
For those who want to understand the 68000 listing
and are used to other microprocessors, remember that the memory for
the 68000 is stored in bytes, words and longwords (.B .W and .L).
Bytes are eight bits long, words are sixteen bits long and longwords
are thirty two bits long. Each is stored in memory as in any
computer but the longword for instance will take up four byte spaces
(4 x byte=32 bits) and it will be stored in memory in, as I would
say, the right way round, that is most significant first then next
significant byte and so on. I think it was done to confuse us mere
6502 programmers! Each byte, word or longword can be put in the data
registers (accumulators), a D stands for a data register and there
are eight of them e.g. D0,D1, and so on up to D7. Each of these
registers is very flexible and can work on up to 32 bit data with
one operation. Wow! The address registers are not quite as flexible
and can operate only on words and longwords. There are eight of
these and they are shown as an A on the listing with a number
following to signify which register is being used. A7 registers
though are used as the stack pointers by the processor. I say
registers because there are two, one for user mode stack pointer and
one for the supervisor mode stack pointer.
When the 68000 in user mode reaches opcodes it
does not understand it enters into supervisor mode and then works on
that command. If it still does not understand however it will stop
the user program. This is how sprites are controlled by the ST, you
just load the address and data registers with the information and
then give the correct opcode so as to confuse the 68000 in user mode
and then it works on the information in supervisor mode. Very clever
stuff, eh? There are many other special codes available to the user,
hundreds of 'em but we will use two, one for drawing the sprite and
another for clearing it.
Drawing the sprite is done with the $A00D opcode
and it is necessary first to load register D0 with the horizontal
position of the sprite and D1 with the vertical position, also you
must load the register A0 with the start address of the sprite
definition block and A2 with the address for where the rubbed out
area of screen will be stored so as to be able to redraw it back
onto the screen when you move the sprite. Then you use the MOD
opcode to confuse user mode and, hey presto, your sprite that was
defined is displayed. Easy!
Erasing the sprite is done with the $A00C opcode,
it is necessary first to load register A2 with the address holding
the rubbed out area of the screen, even easier! The amount of RAM
required for each erased sprite is 74 bytes for mono, 138 bytes for
medium resolution and 266 for low resolution.
The sprite definition block starts with five words
(2 x byte) containing information about the sprite to be drawn and
then follows 32 words defining the shape e.g.
1st word horizontal offset to D0 advised position
2nd word vertical offset to D1 advised position
3rd word ? I am not sure, try and see
4th word background colour of the sprite
5th word foreground colour of the sprite
6th word background bit pattern for sprite's top line
7th word foreground bit pattern for sprite's top line
8th word background bit pattern for sprite's second line
9th word foreground bit pattern for sprite's second line
The pattern continues now as far as you wish till
the maximum of 32 words defining the sprite shape is reached. Each
bit that is set will turn on the corresponding colour for that
pixel, one word equals 16 bits giving a 16 bit pattern for each line
of the sprite.
BASIC listing
Each line
has a background colour pattern of 16 bits and a foreground colour
pattern of 16 bits requiring two words per pattern line with,
naturally, the foreground taking priority.
Speed of draw and erase is fairly rapid considering each sprite is
drawn pixel by pixel into the screen RAM area. I found more than
four hundred sprites per second could be handled, but being
realistic and tying them into vertical blank, BASIC and Assembler
program ran 30% slower when controlling four sprites intelligently.
Remember that when being controlled by VBL they are being addressed
every 1/50th of a second. To put this 30% slower into perspective,
the ST Basic would still be running faster than the Atari 800 and
Spectrum basic's.
Now to the
listings. The BASIC and Assembler listings are the same except for
the routine at address $70000 which is non existent in the BASIC
listing. Apart from that you can compare notes from both listings. I
have included many comments (REM statements) to enable you to fully
understand and have tried to keep the commands simple.
The
routines are loaded into the ST's memory in front of the normal
screen memory which resides at $78000 to $7FFFF and I hope this is
the safest place for linking to the Basic program. Anyway I had no
trouble and it was thoroughly tested. I do foresee a possible
problem though in line 126 in BASIC and in Assembler line 28, this
is where the address for the auto routine is put into the vector
array which on my ST is the correct address, if you have problems
check this. At address $456 (1110 decimal) is a longword that points
to the vector array, so get this and then look at the longword
addresses of the vector array. You are looking for an empty address
(a longword that equals 0). When you find one, that is the place to
poke or move the auto routine's address into.
If you do decide to handle multiple sprites, do not forget to erase
the first drawn sprite last and erase the last drawn sprite first
otherwise when the sprites merge a mess will result, you can see
this if you move the mouse cursor into the drawn sprite (the mouse
cursor is a sprite).
K-SEKA
listing
top
