I've been trying out a new method of scrolling.  It's currently in STOS
but I'm going to convert it into machine code for use in STOS programs.

   Normally, scrolling is done by storing a backup screen (or screens)
for copying out to the display.  This back screen may be shifted around,
and re-written at the edges with data drawn from a map of blocks.  This
gives the impression of a continuously scrolling area but cuts down on
the data storage required for a huge multi-screen area.

   The main disadvantage is that horizontal scrolling by anything other
than 16 pixels is very time consuming.  For 16 pixel scrolls you can just
change a pointer, to offset data by whole words.  For 1 pixel scrolls you
can rotate words in memory, using the carry bit to carry data over from
one word to the next.  Anything more and you either have to store multiple
copies (e.g. 4 screens, each offset by 4 pixels like I use) or use a 
FETCH-SHIFT-STORE method, which is very slow.

   Typically the scroll will be optimised for one speed, so you can't jump
around the map or change scroll speed easily.  Also changes made to the
map must either be made on the backup screen at the same time, or they
won't appear until that part of the map scrolls off the screen and back on
again.

   But what if you could generate the screen every time from the map, with
pixel-perfect positioning?  What if you could display the map from any
position?  Well, that's what I'm trying to do.  (The Sega and Nintendo
8-bit and 16-bit consoles have this built into the hardware.  That's why
you get so many blocky 2D platform games for them).

   I achieve this by keeping the number of scenery blocks low - only 3
here (0=blank, 1=wall, 2=coin).  This gives me 9 possible adjacent pairs
of blocks (0=blank/blank, 1=blank/wall, 2=blank/coin, 3=wall/blank,
4=wall/wall, 5=wall/coin, 6=coin/blank, 7=coin/wall, 8=coin/coin), and it
is these pairs which are the key to the whole thing.

   Although the blocks are 16 pixels wide, as they scroll left and right
they do not always line up with the word boundaries of the screen display.
As one block scrolls out of its 16-pixel wide column to the left, so it
will be replaced by the block to its immediate right scrolling into place.
Now, if I store what this looks like for all the above combinations
(9 pairs, 16 pixel-scrolled frames, each 16*16 pixels in size) you can
begin to see how it works.

   The map is converted from one which stores the 0,1,2 for blank,wall,
coin to one which stores the pair code 0-9, describing both the block at
that point on the map and the one to its immediate right.  You can then
build the display in word-boundary-positioned blocks using the first image
for each pair.  To make the whole thing scroll left, you use subsequent
images from each sequence, so all the pieces move off to the left of their
blocks, and are filled in with the correct image from the right hand side.

   Once you reach the end of the sequence, you move the whole thing along
a block (16 pixels) and start again.  To go right, you reverse the
sequence.  To go up and down, you use offsets to copy the data a bit
higher or lower.

   Now, this runs a bit slow in STOS, even when compiled, but it's not bad
when you consider that you have a go-anywhere, at any speed scroll
routine.  The machine code version should be very quick.

   I've also added a bit of parallax scrolling with a background grid in a
4*4 pattern.  It moves horizontally at 1/4 of the scroll speed by moving
it across behind the blocks as the 16 frames are generated, and it moves
vertically using colour cycling to negate the effect of the vertical
scroll, but letting through 1/4 of the movement for the parallax effect.

   Try my demo, and use the joystick and mouse to see the scrolling.  The
joystick does 4-pixel scrolling, the mouse any speed you like.

   And yes, there is a game on the way.



Jason J Railton

25 November 1997