Parallax Scrolling Demo
***********************

If you happen to know the programmers who converted the stunning Amiga
game UNREAL to the ST as a FLIP SCREEN game, would you kindly drag them
to the monitor and superglue their noses to the screen, then play this
demo for the term of their natural lives...
I was a bit miffed about that conversion...



Run SWING.PRG from the same folder as all the other stuff.  Use the mouse
and mouse buttons to control the sprites in the demo.  Press 1 and 2 to
load the two different sets of scenery.  Press ESC to exit.

I want to know if this runs on a half-meg ST.  If it doesn't, try copying
it all to the root directory of a blank disk, then copy SWING.PRG into
an AUTO folder and boot from the disk.  Not letting GEM start up can 
save a lot of memory.



The idea of this demo is that I'll add swirling patterns of baddies that
you have to avoid, and smash with the glowing ball.  Try swinging it
round you like a sling shot, using the left mouse button and a circular
motion.



All of the scenery is pre-shifted, which takes a lot of memory.  The
data that makes up one full screen is pre-shifted 4 times (foreground) and
16 times (background).  The background is displayed with double-height
pixels to halve the amount of memory used for pre-shifting.  The fact that
the background is two screens wide does not matter.  Only the visible part
is actually pre-shifted.

The sprite routine takes images from a .NEO screen, and is fully clipped
for the screen edges.  Combined with the macros I've written, the sprite
routine becomes fairly powerful.



This demo was a quick test to see if I could do this sort of scrolling.
The only way I could get it to go fast enough (under 2 frames) was to
write  a piece of self-modifying code to display the lines of the screen.
The code copies one line of data onto the screen, drawn from two 
separate sources for foreground and background, and the 'sub' instructions
(that wrap the data pointers from the right edge of the data back to the
left) are actually inserted into the sequence of copy commands just 
before they execute.  Very tricky.

The foreground scenery appears in two bitplanes - colours 0,1,2,3 (using 3
as the transparent index).  The background is drawn in the other two
bitplanes.  Colours 8,9,10 are the same as 0,1,2 and colour 11 is the
first of the background colours (also used for the horizon).  Colours
12,13,14 are also the same as 0,1,2 and 15 is the second background
colour (also used for the moon in the second set of scenery).

Have a look at the scenery .NEO files in an art package to see how the
colours are defined.

The background is copied into the last two bitplanes (colours 0,4,8,12),
but colour 4 is not actually used.  0,8,12 give colours 3,11,15 when
combined with the foreground transparent index of 3, so that 3,11,15 are
the background colours you actually see.   When 0 is combined with
the foreground colours 0,1,2 you just get 0,1,2.  8 combined with 0,1,2
gives 8,9,10 which are defined the same as 0,1,2, so you don't actually see
the background colour 8 unless it's behind foreground colour 3.  The same
goes for background colour 12.  Behind 0,1,2 it becomes 12,13,14, which
look the same as 0,1,2. 

Rasters are then applied to colour 3, for the sky.

By not using colour 4 for backgrounds, this means that colours 4,5,6,7 are
not used for the scenery at all, and can be defined exclusively for
sprites.



The files are:
SWING.TXT    - this text file

SWING.PRG    - the demo program
SWING.S      - the source code, which requires:
 STARTUP2.I  - INCLUDE file for the source code, system intialisation
 LOAD.I      - INCLUDE file for the source code, a file loading macro
 FORCE_TB.I  - INCLUDE file for the source code, a data table

FORCE_TB.BAS - STOS Basic code to generate FORCE_TB.I in assembly language

SWING_F1.NEO - Foreground scenery, level 1
SWING_B1.NEO - Background scenery, level 1 

SWING_F2.NEO - Foreground scenery, level 2
SWING_B2.NEO - Background scenery, level 2 

SWING_SP.NEO - Sprite data



Jason J Railton
March 1997