Abusing PCE hardware for overlapping omnidirectional parallax

[Sadler]

OK, first off, perhaps this is an obvious technique. If so, apologies. Second, no, I haven't implemented it yet. I'm in the middle of a move and things are a bit chaotic. So, having said all that, allow me to speculate.

I was studying Magical Chase the other day, and watching the farthest background layer, it occurred to me that it's possible to have at least two layers of overlapping, multidirectional parallax without resorting to dynamic tiles or sprites, if you are careful about your art. This technique relies on a combination of changing the background color per scan line, changing the x offset per scan line and duplicating scan lines.

First, the background color. This is pretty obvious. Use a gradient, and offset the gradient start to allow it to scroll vertically. Because the gradient doesn't vary horizontally, you don't need to worry about x-scrolling.





Now lets add some tiles. Excuse the horrible copy paste art.



It's pretty common in PCE games to horizontally scroll various portions of the screen at different rates. This is very easy to do in huc, but it doesn't get you vertical parallax. Some games will shift these regions up and down as the screen scrolls up and down, but the layers remain constant in terms of size and position to one another (see ). So, for now we'll set it up so the cloud area scrolls slower along the x axis than the castle area below.



OK, awesome! So how do we get the clouds to scroll at a slower speed vertically than the castle? We selectively duplicate the line just below the clouds, but above where the castle scroll region begins. By duplicating this line, we can move the castle region up or down by the number of lines we duplicate.



Now, with some book keeping to keep the gradient scroll vertically scrolling at the same rate as the cloud vertical scroll rate, it appears we have a complete background layer that overlaps with the castle layer, but scroll independently. The only caveat is that the castle layer can move no higher than the bottom of the cloud layer. Depending on how much you duplicate the line, this could be a great deal of vertical scrolling. Additionally, you could always use sprite caps on the top of the castle layer to allow a bit over lap between the castles and the clouds. Even without that though, it should still appear as two completely independently overlapping layers.

Any thoughts? Am I completely retarded?

EDIT: clarification

[Sadler]

Hmm, it'd probably be smarter to shrink rather than duplicate. You could set up several rows of tiles between the clouds and castle that are just the background color, then shrink them as you want the distance between the clouds and castle to get smaller.

[TheOldMan]

You have extra tiles at the top and bottom of the screen, so.....
Set the castle up at the very bottom of the screen. Start the clouds a few lines of tiles down from the top. Then, when you want to scroll the clouds, you can just adjust the start offset.
If you track the offset, it's pretty easy to fill in a new line of tiles, and re-set the offset.

That gives you a top area that scrolls (and wraps, if need be, by careful copying) vertically and horizontally (since you can change the X offset, too). And you wouldn't need a gradient at all...

[Bonknuts]

Treating the BG color #0 as its own plane, isn't that common on the PCE. But like you've thought about, it's pretty easy to do. Just need a proper hsync routine and change the BG color are each specific scanline. Mimicking a display table list or HDMA or such is pretty easy. You just set the first RCR line as the top Y position, then Hsync routine loads all spaced proceeding calls/lines from a index+table. Makes scrolling such an 'layer' pretty simple.

 Slightly off topic, but changing the BG color #0 was a pretty popular trick on the Amiga to create another scroll layer for games using single plane mode. You can even mix in some sparse low tile priority sprites along with 'bars' to create more advance BG color #0 designs (Turrican 3 on Amiga, IIRC does this) - without killing your sprite scanline limit.

[Sadler]

You have extra tiles at the top and bottom of the screen, so.....
Set the castle up at the very bottom of the screen. Start the clouds a few lines of tiles down from the top. Then, when you want to scroll the clouds, you can just adjust the start offset.
If you track the offset, it's pretty easy to fill in a new line of tiles, and re-set the offset.

That gives you a top area that scrolls (and wraps, if need be, by careful copying) vertically and horizontally (since you can change the X offset, too). And you wouldn't need a gradient at all...

Good idea! Unless I'm misunderstanding you, you couldn't give the perception of overlap this way though? The gradient allows some perceived overlap between the background (clouds + gradient) and the foreground (castle apparently overlapping the clouds+gradient, but really just overlapping gradient).

[TheOldMan]

you couldn't give the perception of overlap this way though? The gradient allows some perceived overlap

Oh, that's why you want the gradient in there. I wondered about that.
No big problem, though. You just make the gradient a non-scrolling area; you could theoretically even shrink it to just a few scan lines (though it would still take a whole row of tiles in the BAT).

You would need a few more scroll areas than Huc provides, though. At least I think you would.