Horizontal Parallax Bitplane Scrolling Demonstration

[joefish]

Here's a couple of demos of parallax scrolling on separate bitplanes I wrote years ago. I'm afraid I can't show you the source code at the moment - I may still have it on a disk somewhere - I recovered these from the ICTARI programming group disks #45 and #48. It was planned for a Hysteria-like game (scrolling punching game with wrap-around levels) but I got side-tracked by an idea I was calling 'SwingShot' that didn't quite work. In that you control a puck with the mouse, and by pressing the mouse button you can pull a powerball towards you, swing it around your puck, and hurl it at enemies. In the first demo it's just the puck and the ball. In the second demo, there are enemy sprites too.

http://railtron.com/files/atarist/Joefi ... x-Demos.st

In the first demo, you can press [1] and [2] to switch beteen an Autumn and a Winter scene. This doesn't work in the second one. In both, press [ESC] to exit the demo. Here's a screen grab of the second one in action:



To explain what's happening, there are three layers of scenery. The scrolling foreground is copied into the first two bitplanes, and the scrolling background into the other two. That narrow, static horizon line is ORed into one bitplane of the background. In the winter scene you can see a moon too - that is masked and drawn into the two background bitplanes.

[joefish]

As for how the palette is arranged, you can see some of it in the .NEO pictures that get loaded in. Here's a foreground image:



It's drawn in colours 0, 1 & 2 and uses 3 as transparent. Instead of trying to arrange things so that 0 is not used and can be black for the border, I simply arrange that 0 is the darker of the foreground colours. That the border then matches seems to work quite well. On the Amiga, you have to use 0 as transparent, and Shadow of the Beast then goes to great lengths to make sure that colour 0 is black in the border, but multi-coloured for the background sky. I think this is a much simpler solution.

Now here's the background from the Winter scene:



This is effectively drawn in colours 0 (sky), 8 (dark) and 12 (light), but since it will only ever appear through colour 3 of the foreground, it shows up in the final view as colours 3, 11 & 15. Colour 3 is the one that gets rastered as a multi-colour sky.

You'll also notice that it is drawn in half-height (it gets doubled up when rendered) and is two screens wide. The graphics for the horizon and the moon appear across the middle.

[joefish]

Now to render it, the background is stored pre-shifted to all 16 pixel positions. It's half a screen high, two wide, but only in two bitplanes, so all that comes to four screens worth, or 128K. The foreground is pre-shifted to four-pixel positions. Again, only in two bitplanes, so that's two screens worth of data, or 64K. Then there's a display screen and a hidden work screen, another 64K. So 256K so far. It does still run on a 520ST.

The screen is rendered by treating the foreground and background as two rotating buffers, and copying from both to the working screen on the interleaved bitplanes with a bit of self-modifying code to make the source pointers wrap-around part way through copying each line. The background is doubled up in height, then the last line re-used to fill any remaining space at the bottom of the screen. The horizon is ORed into one of the background bitplanes across a narrow band in the middle of the screen. It appears as the darker of the two background colours, but seems distinct enough as it doesn't move. The moon takes a mask from the darker bitplane before being ORed in to both background bitplanes, so it shows up in the lighter colour.

It also loads in a screen of sprites, and has a (not hugely efficient) sprite routine to copy, shift and mask 16x16 sprites from the sprite screen to the work screen.

And it's doing all this at 25fps.

A couple of things to note - I found that when you ask the OS for a mouse position, the keyboard chip replies with an interrupt of higher priority than the rasters, causing the colour bands to twitch. So I'm actually counting raster bars and requesting the mouse packet around 3/4 of the way down the screen, so the response comes in bottom border time.

But the main thing to note about this routine is that, by only using three colours in the background, colours 4, 5, 6 & 7 never appear in the scenery, either on the foreground, background, or where they overlap. These can therefore be re-defined for use by the sprites. In this case I draw the sprites in any of these four colours or any of the foreground colours (i.e. colours 0..7), and that leaves the fourth bitplane of the sprite screen to define their bit-masks.

[joefish]

Another note - here the foreground just wraps round. For the actual game, the foreground was supposed to be 8 screens wide (to match the wrap-around background moving at a rate of 4:1) and be block-mapped with 32x24 pixel blocks. The 4 foreground pre-scrolled buffers would be wider, with dead space either side of the viewable bit for adding new blocks.

Now for each 4-pixel scroll, a block would be drawn off the edge of the first buffer and then be shifted in 4-pixel steps and drawn into each of the other three buffers. By the time you'd scrolled a whole block (32 pixels) 8 new blocks would have been drawn to fill in the edge of the scrolling window. And if you scrolled the other way, they'd be added to the opposite edge.

[simonsunnyboy]

Thank you for the explanation and demo. This makes things a lot clearer.

Only drawback seems waste of color registers used for bitplane overlap effects.

[Cyprian]

looks cool.
how much cpu time is used?

[joefish]

Yep, it's an obvious disadvantage to duplicate the colours like that, but it's a hell of a difference in speed compared to trying to treat the entire foreground as a software sprite. I think though by not throwing all the colour registers at the parallax and keeping a few back it's a decent compromise. (In total, 6 out of the 16 colours are lost to duplication - you can see them under the foreground pic - whilst 4 are completely independent for sprites).

What I would like to do sometime is have a smarter raster routine; one that can grade the sky like that but also re-write half the palette in, say, three larger bands. That'd let me change the background colours entirely to do separate clouds / mountains, like SotB, and change one of the foreground colours (which needs setting in 3 places) so the green of the tree-tops could become grey for a rocky ground. Agony does this to good effect on the Amiga, to get extra colours into its middle layer.

Time wise, it's running at 25fps. And it takes up most of those two frames when it's drawing the full complement of sprites you see in the second demo. Although none of the routines are particularlay optimised. I can't remember exactly what it took just doing the scenery, but I vaguely remember it was about 1.3 - 1.4 frames to render the whole 320x200 screen.

[joefish]

Actually I think I have my sums wrong - that background must be around 256K once pre-shifted (which is quite a bit to be honest), so that's 384K of buffers. It has been 19 years since I saw the source code!

[EvilFranky]

Just tried the demo on Hatari, it's good...I can't remember seeing the effect made so well on a plain ST.

[joefish]

Thanks. The irony is I was inspired to attempt it after seeing screenshots like this of Unreal on the Amiga:



When in fact that darker line of trees isn't a separate layer at all - it moves with the foreground. Only the very narrow horizon line and the moons move relative to the foreground.

Unreal also highlights another major drawback in scrolling on the Amiga - it has no screen wrap-around function. I presume the STE is the same? So to do continuous scrolling, you have to define a virtual screen two normal screens wide, and slide the viewport along from one to the other - but making sure that the space you're leaving behind is filled with an identical copy of the new view you're moving into. Then, when you reach the far edge of the virtual screen, you jump back to the beginning again. Unreal doesn't have continuous scrolling though. These levels are a few screens wide, and the view just pans from left to right, and then you walk off the right-hand edge to end that level. It's all a bit cr@p really, but I didn't know this at the time - all I saw were these amazing screenshots.

Agony is more of a showcase of Amiga scrolling, and more like what I'm doing here. Though that's using the back three bitplanes of dual-playfield mode as two separate layers in themselves. I don't think I could afford to OR in another full screen of backdrop though, but I do like the fixed horizon.

SotB III is a really good Amiga scroller - multi-directional with a couple of layers in the background (though I notice the background doesn't move vertically) and some extra foreground effect, like the original, when you're running along at the lowest level.

I probably should have a crack at imitating the original SotB with this bitplane technique, since it always seems to come up as the benchmark!

[Zarchos]

Very, very interesting thread.
Thanks a lot for posting.
Could somebody remind me on the ST, STE, Amiga including AGA (and the Falcon that'd be great too) if the memory buffer used for the screen memory can be anywhere in memory and/or an ysize or if there's a limit, and what these are ?
I believe on the Amiga the Fat Agnus chip extended the possible size of screen memory from 512 kbytes to 1 Mbyte, but I'm not entirely sure.

Speaking of SoTB and sorry to be off topic but have you people got some links to download all the graphics including the animations ?
Not only from the Amiga version but from other versions where who knows the graphics are even better ? I'm thinking of the PCE version for example, or better FM-Towns.
Is there any SOTB like effect on the Falcon in a demo ?

[joefish]

All I know is that on the ST the screen can be displayed from anywhere in RAM, though it has to start on a 256-byte boundary. And obviously the operating system grabs some RAM so you have to avoid that. I never really looked at the memory map in detail though. I just let it load and run my code, and allocate me spare RAM on request.

[dml]

Unreal also highlights another major drawback in scrolling on the Amiga - it has no screen wrap-around function. I presume the STE is the same? So to do continuous scrolling, you have to define a virtual screen two normal screens wide, and slide the viewport along from one to the other - but making sure that the space you're leaving behind is filled with an identical copy of the new view you're moving into. Then, when you reach the far edge of the virtual screen, you jump back to the beginning again.

Thanks for the interesting read.

In fact what you describe here is what I termed 'loopback scroll' in my ST/STE scrolly playfield engine. You can do this on both axes to provide 'infinite' playfields (within reason, subject to number ranges and map/tile storage of course).

However there's another mode which I termed 'scanwalk' which allows the same scroll range on the horizontal axis, with less memory and drawing expense for up to about 200 screens - then it would start costing more ram beyond this. Usually it's enough though!

To apply 'scanwalk' you just need enough hidden/virtual margin for updating 2 columns of tiles (or 3, depending on your tile update algorithm) and continue advancing the screen address without wrapping, allowing it to consume a virtual scanline of 'walk' for every screen scrolled. This only requires a single buffer - no jumps back to the 'clone' buffer, plus enough padding scanlines for the maximum 'walk'. Unfortunately this only works on the H axis. For the V axis you need stick with loopback mode or a screen-split raster (and suffer the pain of splitting sprites!).

On STE this just requires the lineskip register to reserve 4*2 or 4*3 words of display margin. On STF it requires syncscroll, loads of ram and repairs to the physical screen - the method still works.

Cheers,

[joefish]

Yep, that's the issue with hardware scrolling if you do have a screen pointer you can set to any word position. Once you've scrolled a whole screen to the right, you're actually one pixel row below where you started in memory.

In my code, I have an 'unrolled' list of instructions to copy one line of data from the back buffers to the work screen. I use self-modifying code to insert some SUB instructions somewhere into that code so that the 'from' registers can be made to loop back to the start of a line part-way through copying it. That way I can treat my memory buffer as if it does wrap-around. Though this only works if you're copying from a buffer; it doesn't work for the actual display.

[lotek_style]

Ok I couldn't resist

http://demozoo.org/productions/154820/

http://demozoo.org/productions/154819/

[joefish]

W00T!

I just found the source code for the first demo. My PC floppy drive is knackered and can't read my ST disks at the moment, but I found some of my old source on one of the ICTARI disks. Most vital (and missing until now) were my startup / exit and file loading libraries, which were in separate files.

Anyway, you can download the full bundle from here:

https://dl.dropboxusercontent.com/u/719 ... rallax.zip

One interesting thing I found out is that it doesn't actually pre-shift the entire background. It stores the 640x100 background it extracts from the background .NEO once in full, then stores 16 x pre-shifts of only one screen width (half of it), which takes 128K, not 256K. It then rotates in chunks from the whole background image in a rolling-buffer style, similar to how you would fill in the edges from map tiles.

So I can already see several efficiency improvements I could make to this code going forward.

Note that in the code I'm using mostly decimal numbers, so a screen is 32000 bytes rather than 32768 or 0x8000. Try not to get confused as there are some #8000s in there that genuinely refer to 8000 bytes - the size of one background pre-shift buffer. Because I use decimals, I'm also using multiplies a lot to work out addresses where I could use more binary-friendly buffer sizes and then use shifts in the calculations.

There's also a bit of STOS in there, which calculates the repulsion table that pushes the powerball away from the puck as you get close. I don't know if you've noticed, but you can nudge it around at the edges, but you can also press the right mouse button to dip into the background, then pop up right under the ball and send it flying.

[joefish]

Hmm - just found out there's an enormous bug in this code!
The definition line that calculates the memory workspace required has spaces between the terms, which the assembler assumes is the end of the line and everything else is a comment! A bit ridiculous syntax really.
So TOS is only actually allocating me a small fraction of the memory I intend to ask for, and I'm just writing off the end of it into the rest of the RAM. Fortunately it's not giving me an error or over-writing anything critical, but I wouldn't ever know if I was asking for too much RAM from the system.

I've fixed this in my attempt to write a Beast scroller in this style, and I've added some debug readouts so I can see the memory usage.
Do other programmers actually use TOS to allocate them RAM, or do you just assume the operating system sits in low memory and you can just go on writing into all the RAM that comes after your program?

It seems to me on a 512K machine (emulated) that TOS is taking up about 100K (I gather you can reduce this by auto-booting - anyone know by how much?) and that includes a single screen display (it's not using a back-screen, is it?). So my code loads in, I allocate myself another screen, with a bit of header space so I can load it directly from a .NEO file, and that's about 137.5K gone. Does this sound about right?

What's TOS doing with all that memory?

[joefish]

OK, for my Beast version of this I have the trees and mountains going, and just finished the clouds last night.

The clouds were tricky as they all need to go at different speeds - some slower than 1px per frame - and could take a lot of data in pre-shifting. So I've cut them down to half a screen width but draw each strip twice, and re-used the cloud patterns so I only have 3 different strips but get 5 rows out of them. Of course the Amiga didn't have this problem as it just had one background screen you could draw anything on and slid individual lines of it left and right.

Doing the full height of trees, clouds and mountains in parallax has finally tipped it over into a second VBL. With all the clouds going the same speed as the mountains, it could just do it in one VBL. Next up is the ground at the bottom of the screen and the fence.

Lastly a player sprite. And maybe a moon. But capturing clear images of either from the Amiga game might be tricky.

[Ragstaff]

Watching with interest, Joefish!

[galax]

This is very cool, good to see the tradition of Beast-style demos being continued! I like the trade-off of bitplanes for speed, I wish more ST games had been willing to sacrifice colours. I was thinking about ways in which the approach differed to earlier demos, and came up with this list of Shadow of the Beast-style scrollers:

Kill the Beast 2 from the Vodka Demo by Equinox: http://www.pouet.net/prod.php?which=4163

Main menu of Rip Dis by NeXT: http://www.pouet.net/prod.php?which=21383

Ripdis_00002.png

Phaleon Gigademo by NeXT: http://www.pouet.net/prod.php?which=496

Pompey Pirates Disk 53 Menu

PP_053_00003.png

[Ragstaff]

Great post Galax, I actually had been going to make a video about some of these SOTB demo's "one of these days", but I wasn't aware of the PP53 one! Will hold off until joefish makes this contribution as well

[joefish]

Yes, I've seen a lot of these, and they're full of the usual boasts by demo coders about what they've achieved, whilst very few are in any way practical as a game engine. Or boasts about layers of scrolling when there's no actual overlay - it's all just separate strips.

I mean, look at that 'Kill The Beast' one - there's an obvious palette swap between the trees and the ground, whereas in the game there are ramps and vertical scrolling, which means this is completely impractical. And the text and sprites never actually cross into the space where the trees are overlapping the backdrop, as that's it's own special region where all the bitplanes and colours are otherwise occupied.

Then the 'Phaleon' menu - it's very impressive - fast hardware scrolling with the borders taken away - but it's obviously using three bitplanes for the scenery, then one for the monochrome backdrop in the upper part of the screen, then the backdrop becomes solid black further down which frees up 8 colours for the player sprite. The player sprite is unable to jump up to cross that line, and any enemy sprites would have to be drawn in the same palette as the foreground scenery if it were required to move up or down in any way.

The Ripdis one is new to me (oh look, lots of swearing, that's novel...) but again the only overlaid bit is well above the head of the player.

Having said that, Beast III on the Amiga actually pulls off a similar trick. The foreground scrolls in eight directions, but the background doesn't; only horizontally. And the player's sprite always remains in exactly the same spot in the lower third of the screen. There's no way for the player to ever overlap the background strip. My guess is it's not using playfields - the background is actually a repeated row of hardware sprites, and below that, those sprites are recycled to display the player. That leaves the full 32-colour palette for scenery instead of the 8-colour layers of the original Beast.

So maybe some of these tricks could work in a game - the Phaleon one for instance could work in the same way Beast III does if it had 4- or 8-way scrolling; perpetually keeping the player away from the actual overlaid parallax bit with a fixed player vertical position.

And 'Kill the Beast' could pull off a palette switch between the trees and the landscape so long as (a) the palette switch can be moved up or down with the scrolling - which is tricky when the rastered sky has to stay still - and (b) the trees are only placed on the tops of hills or well-away from slopes. I suspect Beast II on the Amiga is actually doing something along these lines anyway.

[joefish]

Just a quick screen grab to show what it's looking like so far. This shifts at the same rate as the Swingshot code above; 4 pixels foreground, 1 pixel background at 25fps. The clouds all go at different speeds.



The clouds and mountains are two colours (with a raster split between them), and the trees are just three colours. I'd like to add more raster splits to the sky, but there isn't really enough precision in the basic ST palette to grade it any finer. With optimisation this may all just be possible in one VBL, but I'd have to stop there. The fence and any sprites are definitely going to take it into two VBLs.

One thing I notice playing ST Beast again, once you get underground, the screen is done with a neat bitplane parallax scroll (monochrome background and three-colour foreground) with other colours assigned ad-hoc for sprites. And it all runs smoothly. The choice of colours might be improved (when limited to three colours, don't use three shades of the same colour- two shades maybe, but use the third to add something extra). But gameplay wise it's fine. It's only above ground - trying to draw the trees as huge software sprites - that the game slows and stutters and looks a mess.

[punkrulesok]

thanks Joefish, a really interesting thread. Be keeping an eye on your SOTB code.

[joefish]

OK, it's not finished yet, but here's something you can run. Here we see your man making a mad dash to the right pursued by some sort of flying bunyip.

The only sprites I could find on the internet weren't very tidy, so I might do a few fixes to the animations. Or if anyone else wants to have a go they can. All the graphics are in plain .NEO files, though the colours are fixed in my code so shouldn't be altered. The bat has been taken from a sprite sheet I found based on the Megadrive version. It's got 8 frames of animation, though really the last 3 are redundant as they're simply copies of earlier frames in reverse order.



http://railtron.com/files/atarist/Joefish_Beast010.zip

The clouds, mountains and turf at the bottom are two colours each with a raster split between them, and drawn into the last two bitplanes. The moon is added in in one of the cloud colours. The colour behind them all is also changed on the raster, from blue to pink then two shades of green. The trees use three colours, one of which is re-assigned so that the fence can be drawn in the same range. These use the first two bitplanes.

Setting all the appropriate colour combinations leaves four colours undefined. These are set to two shades of grey and a red for the hero, with the last one being set to pale green for the baddie (in-game, this last one would vary depending which baddie is on-screen). The sprites can use any of these four spare colours, along with any of the three foreground colours.

Timing wise, it's still only taking about 1.3 VBLs to render. The actual game features so few sprites there's easily enough time to shift the few that are needed rather than having to pre-shift all the animations.

I want to make it joystick controlled so that you can run left/right and jump, and then I'll use up the rest of the (512K) memory with more scenic objects.

I've no idea about sound. If anyone wants to volunteer a simple tune and tell me how to play it I could add that, memory willing.