Автор: Rick O'Neill
Год: 1990
Издатели: Your Sinclair
Языки:
Английский
Формат:
TAP лента
Требования:
ZX Spectrum 48K
Ссылки:
Страница на ZXArt
Страница на World Of Spectrum
Страница на Spectrum Computing
Скриншоты:
Год: 1990
Издатели: Your Sinclair
Языки:
Формат:
Требования:
Ссылки:
Скриншоты:
MASKULINITY
by Rick O'Neill
Right, hands up who knows what a masked sprite is. Hmm. Well, perhaps
I'd better explain. You see, the trouble with ordinary sprites is that
they tend to leave a trail of devastation behind them. Move them over
a background of any kind and they'll tend to muck it up completely.
Not so with masked sprites. These little devils cunningly keep a copy
of whatever they pass over and replace it when they move on. They also
have the advantage that you can see through them, where appropriate.
This is where Pitstop veteran Rick O'Neill's handiwork comes in. He's
done all the hard work for you, and has come up with a complete
masking package which even boasts its own demo.
As you might expect, getting it going isn't going to be easy. On the
face of it, this one looks like a straight "type in the Basic, save it
with SAVE "SPRITE" LINE 9800, and then type in the hex using the hex
loader and save that after the Basic" job. And indeed it is. Do so,
run it and you'll find yourself staring at the wonderful demo routine.
This, however, is just a taste of things to come. The next step is to
do your own thing with it, a much more tricky feat altogether.
The first step is to define your sprites, and store them in memory.
They're stored upside-down (it sez 'ere), a row at a time, with two
bytes for the sprite being followed by two bytes for the mask each
time (the mask shows which sections of the background are to be
blanked out and then restored each time the sprite is moved). The
program also needs to store a copy of the background screen, so plonk
one at any address that's a multiple of 256 by doing RANDOMIZE USR
33316 (or 33327 if you've already stored one). The best way of doing
all this is to make use of the relocation routine in the Basic
program, which should explain it all miles better than I ever could.
Then poke in the X and Y coordinates and the sprite number (check out
the Basic once again for details) and RANDOMIZE USR 32768 to set the
ball rolling (or alien, spaceship, elephant or whatever).
Alternatively, machine code fans can call Start Address + 4, with IX
holding the address of the sprite information. The format is
x-coordinate, y-coordinate, sprite number followed by three bytes used
for information about the last sprite printed.
And if you can work out what's going on there you probably ought to be
contributing to Pitstop yourself.
by Rick O'Neill
Right, hands up who knows what a masked sprite is. Hmm. Well, perhaps
I'd better explain. You see, the trouble with ordinary sprites is that
they tend to leave a trail of devastation behind them. Move them over
a background of any kind and they'll tend to muck it up completely.
Not so with masked sprites. These little devils cunningly keep a copy
of whatever they pass over and replace it when they move on. They also
have the advantage that you can see through them, where appropriate.
This is where Pitstop veteran Rick O'Neill's handiwork comes in. He's
done all the hard work for you, and has come up with a complete
masking package which even boasts its own demo.
As you might expect, getting it going isn't going to be easy. On the
face of it, this one looks like a straight "type in the Basic, save it
with SAVE "SPRITE" LINE 9800, and then type in the hex using the hex
loader and save that after the Basic" job. And indeed it is. Do so,
run it and you'll find yourself staring at the wonderful demo routine.
This, however, is just a taste of things to come. The next step is to
do your own thing with it, a much more tricky feat altogether.
The first step is to define your sprites, and store them in memory.
They're stored upside-down (it sez 'ere), a row at a time, with two
bytes for the sprite being followed by two bytes for the mask each
time (the mask shows which sections of the background are to be
blanked out and then restored each time the sprite is moved). The
program also needs to store a copy of the background screen, so plonk
one at any address that's a multiple of 256 by doing RANDOMIZE USR
33316 (or 33327 if you've already stored one). The best way of doing
all this is to make use of the relocation routine in the Basic
program, which should explain it all miles better than I ever could.
Then poke in the X and Y coordinates and the sprite number (check out
the Basic once again for details) and RANDOMIZE USR 32768 to set the
ball rolling (or alien, spaceship, elephant or whatever).
Alternatively, machine code fans can call Start Address + 4, with IX
holding the address of the sprite information. The format is
x-coordinate, y-coordinate, sprite number followed by three bytes used
for information about the last sprite printed.
And if you can work out what's going on there you probably ought to be
contributing to Pitstop yourself.