are there any parallax machine code scrolling routines out there?

[Lethargeek]

@Joefish
well... Valley of Rains is a 48k game... a full game, not a demo... with up to 4 layers of parallax, up to 3 of them overlapping

Edited by PJ

[777]

Fullscreen parallax scrolling is quite expensive in terms of CPU power on Speccy.
How big area of screen you want to scroll and how many layers you would like to have ?

at least half with 6 or so layers...

[777]

A more direct answer to the question posed in the topic title though, is yes.
Stuff like this:
https://spectrumcomputing.co.uk/entry/8 ... upercode_3
Contains a bunch of routines for scrolling areas of the screen by pixel or by char square, which can be combined for parallax effects.

the problem with the box routine is that it doesnt wrap around and if you try and add any characters to the scroll it doesnt move any of them at all.

[catmeows]

Fullscreen parallax scrolling is quite expensive in terms of CPU power on Speccy.
How big area of screen you want to scroll and how many layers you would like to have ?

at least half with 6 or so layers...

And you want to call it from Basic?

[Joefish]

well... Valley of Rains is a 48k game... a full game, not a demo... with up to 4 layers of parallax, up to 3 of them overlapping

It's a very good example.There's a lot you can learn from it. Take a close look at the spiny black treeline at the top - see how it repeats every 64 pixels. That means you only have to scroll (or pre-shift) a smaller rotating patch 8 characters wide, then just duplicate it four times to make the full screen width. And if you're short of memory, simply cut this patch down to a 32 pixel wide repetition instead. Or if you've got memory to spare, make a wider rotating patch.



You can see from the bright cyan spikes on the midground layer, it repeats twice. But take a closer look and you can see a smaller patch that repeats at different levels. This is probably drawn from a limited character set that is scrolled or pre-shifted in place. The tricky bit is not just each UDG is unique, but once you start pre-shifting a scroll, each pairing of a UDG and the one to the right that scrolls into it becomes unique, and you need to have enough UDGs to cover all combinations that might occur in your scene. So again, keep the design simple, and again, it becomes a very dedicated function tailored around the scenery. But being drawn with whole UDGs, it's easy to overlay part of it over another layer; you just don't draw the empty UDG cells on that layer, and whatever's behind will show through (see on the second level, where tall mushrooms appear on this midground layer).

I presume from level-to-level, it's very flexible about how much memory can be devoted to each layer of graphics depending on the effect required. Note how on level 2, with the more detailed middle-ground, that 64-pixel wide background tree line is much lower than on level 1. And although it's 48K and all in one load, it'll be un-compressing and pre-shifting data into a temporary cache at the start of each level, rather than have everything ready at LOAD time.

And it does highlight another useful technique, commonly used in NES games - having a coloured skyline that becomes black after the top row of scrolling. Then as long as you dither something into the black background, any number of scenery rows or sprites can be used as more parallax.

The other advantage to having parallax layers is you can get away with loads of repetition, as the different combination of foreground and background mixes things up into more combinations for you. And also very sparse or simple foregrounds: look how one tree trunk on the whole screen is sometimes enough. Or just one window showing the background repeated multiple times. Again, write code to exploit this, and not spend all the time dealing with empty areas of a layer's graphics.

[Joefish]

Here's another earlier example, Hysteria.

Note the background carries the most detail. This is a 27x16 character area built from a map of blocks that scrolls 1 pixel at a time. This is typical of Joffa's games; just like the scenery in Green Beret. The working screen area is wider, but the left and right edges are chopped off and hidden by black attributes to (a) hide the areas where new scenery blocks are being added and (b) allow sprites to over-run the edges of the screen rather than needing to clip them in software. The scenery blocks themselves don't need pre-shifting. They just scroll along with everything else once they're copied into this big scenic buffer. Slightly disappointing that there's no split between the pillars there and the mountains, but elsewhere in the level there are temples tall enough to cover up those mountains, and they're done all on the same layer.

Each frame, the game can scroll this whole patch of screen 1 pixel left or right, then copy it up to refresh the display. Below it are two bands that move at different speeds. But note how both are identical pixel-wise, and repeat every six characters. These will have been pre-shifted to 4 different pixel positions (moving in two-pixel steps), then drawn using a combination of picking the right pixel pre-shift, along with a whole-byte wrap-around copy function for coarser positioning.

[777]

And you want to call it from Basic?

not necessarily...

[PeterJ]

Hi @777. Can you give us an idea of your programming experience and stuff you have developed previously? It might help people pitch stuff at the appropriate level

[777]

Hi @777. Can you give us an idea of your programming experience and stuff you have developed previously? It might help people pitch stuff at the appropriate level

i am fully versed in basic. and a beginner at assembler. i have written some small programs myself and can understand what some of the instructions do. i know about memory and screen mapping. i have made a file browser in basic and a few games, some unfinished. i started a space invader clone and finished it apart from the udgs.

[777]

Hi @777. Can you give us an idea of your programming experience and stuff you have developed previously? It might help people pitch stuff at the appropriate level

i am fully versed in basic. and a beginner at assembler. i have written some small programs myself and can understand what some of the instructions do. i know about memory and screen mapping. i have made a completed file browser and database in basic and a few graphics demos. also a few games, mostly unfinished. i started a space invader clone and finished it apart from the udgs.

[PeterJ]

Thanks @777

Useful.

Can I suggest you may want to get the basics under your belt before attempting something as advanced as this?

The free book by Jonathan Caldwell on getting started with creating Spectrum games is excellent, and it only assumes that the reader knows the basics of assembly language (at least in the earlier chapters)

https://spectrumcomputing.co.uk/entry/2 ... trum_Games

Darryl Sloan has also produced an excellent PDF along with a YouTube series:

viewtopic.php?p=48652#p48652

I'm never going to be a master machine code author, but both these resources got me to a level I'm content with.

[777]

The free book by Jonathan Caldwell on getting started with creating Spectrum games is excellent, and it only assumes that the reader knows the basics of assembly language (at least in the earlier chapters)

yeah, ive looked at and used this book

i think i saw some of those videos too...

[PeterJ]

Great @777,

You should be able to write a simple game after reading those two titles.

[777]

something weird did happen when i tried to put a too high a number into the width poke, which looks like parallax, spooky...

type goto 9900

https://easyupload.io/dplksm



no idea why thats happening...

[Sokurah]

Can I suggest you may want to get the basics under your belt before attempting something as advanced as this?

I have to agree.

If he can't figure out the problem here ...

Code: Select all

org 40000
call 3503
ld a,0
start
inc a
rst 16
jp start

... then it's too early to try and get a grasp on parallax scrolling

[PeterJ]

... then it's too early to try and get a grasp on parallax scrolling

Absolutely @Sokurah.

Please take these as constructive and supportive comments @777. This is certainly how they are intended.

I get excited when I manage to get a single character UDG moving around the screen!

Maybe look at Boriel BASIC. You get the simplicity of BASIC with the speed of machine code. This runs on a PC but creates Spectrum files.

Also, look at the Softek FP Compiler. That's good fun and accepts most BASIC commands, and also has good documentation:

https://spectrumcomputing.co.uk/entry/8 ... l_Compiler

[Morkin]

something weird did happen when i tried to put a too high a number into the width poke, which looks like parallax, spooky...

type goto 9900

https://easyupload.io/dplksm



no idea why thats happening...

Out of interest, where's that from?

I had a quick look. The BASIC program seems to have 4 POKEs that affects what the code does.

Code: Select all

9921 POKE 58679,0
9922 POKE 58680,64
9923 POKE 58681,50
9924 POKE 58682,100

The first two POKEs are the screen position to start the scroll at (picked up by HL in the assembly code).
So it's 0 + (64 * 256) = 16384 (start of screen display).

I think you might want to change this to the position at the end of the row because it's it's scrolling left (though I may have missed something). So try setting them to 31 and 64 (respectively) to put the screen address at the rightmost character of the row.

The third POKE at 9923 seems to be the number of pixel rows to scroll. So you could POKE it to 16 to scroll two full character rows.

The fourth POKE at 9924 is the column row to start at I think [Edit: Sorry, number of columns (counting from the right, as it's scrolling left)]. So if you're scrolling the whole row left, try poking it at 32.

I think that should scroll the top two character rows of the screen. If you POKE too high for the third & fourth parameters, you're possibly to get odd effects.

I reckon you'd have to refine/adapt the routine a bit for a game though (unless it was a Frogger-type game which just scrolls one line at a time). Maybe trying to get the top two character rows scrolling twice as fast as the next two would be a good practice exercise.

[777]

here

https://spectrumcomputing.co.uk/entry/8 ... upercode_3

i put a too high poke in on purpose btw... i understand what the pokes do.

[Morkin]

here

https://spectrumcomputing.co.uk/entry/8 ... upercode_3

Ah - I see...! There's actually instructions for that in the entry. I guess it's either the "Right to left scroll" or the "Box scroll" option.

The instructions tells you what to POKE - only thing is with routines like this, it doesn't really explain how the routine works, and the code within it.

One thing you could try doing is fire up ZX Spin, launch the debugger and put a breakpoint on the start address (58571). Then then when you GOTO 9900 it'll stop. You can step through the code in the debugger to try to figure out what it's doing.

[PeterJ]

@777,

If you are more interested in pre-built routines, take a look here:

https://spectrumcomputing.co.uk/entry/2 ... X_Spectrum

And here:

https://spectrumcomputing.co.uk/entry/2 ... r_Spectrum

Both include scrolling routines.

[Joefish]

Please consider having a go at this:

viewtopic.php?t=7113

[777]

https://spectrumcomputing.co.uk/entry/2 ... r_Spectrum

Both include scrolling routines.

yep, that one works!!!!