The program presented here ("U.PARSTAR") is much the same - with one major difference. The stars now move at different rates, giving the impression that stars that are closer are moving faster. That's the parallax effect; a bit like when you are travelling along a road and look at the scenery. The houses going by seem to move move quickly than the trees behind them.
How's it done? It's quite simple, really. All we do is add one to the position of even-numbered stars, so they move more slowly than odd-numbered stars to which we add two.
To make this easier, instead of storing two-byte screen addresses of each point in TABLE, we store the x and y co-ordinates of each point. In all modes there are 256 rows of pixels down the screen, numbered zero to 255. How many columns there across the screen depends on the resolution of the Mode we are in. In Mode 2 there are 80 columns across the screen numbered 0 to 79. TABLE is arranged as 30 x co-ordinates followed by 30 y co-ordinates.
BACKDROP then picks up the co-ordinates and calculates the screen address using CALC, before storing the point in the screen RAM. Notice that the stars aren't all white as in the original demo. So if you were stuck with my suggestion about how to make them different colours then take a peek at the coding in this issue's program.
The X register indexes into TABLE, and we take the bottom 3 bits to be another index into CCODES. A byte on the Mode 2 screen holds the info about the colours of two pixels. For example, the first entry is 1, the code for black-red, the second entry is 4, the code for black-green, and so on. This is the byte that's finally stored in the screen.
The macro FNequb allows us to assemble as many bytes as we want provided they are separated by commas and enclosed in quotes. Normally we would use eight separate EQUBs:
EQUB 1:EQUB 4:EQUB 5:EQUB 16:EQUB 17:EQUB 20:EQUB 21:EQUB 64
but that takes up a lot of memory and also a lot of typing. Of course, we could have done:
EQUD &10050401:EQUD &40151411
While this is concise, it isn't very clear what the numbers mean. It may take more time for the BBC or Electron to decode the string provided in FNequb - but it's a lot clearer.
SCROLL moves the stars by adding one or two to a star's y co-ordinate. We simply take the least-significant bit of the X register (TXA:AND#1), LSR it into the Carry, then ADC#1. The value added will be 1 or 2 depending on if the Carry was set or clear.