Horizontal scrolling solutions #1457

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Joefish
Berk
Posts: 49
Joined: Tue Nov 14, 2017 10:26 am

Re: Horizontal scrolling solutions #1457

Post by Joefish » Mon Nov 20, 2017 12:52 am

My original River Raid Tech Demo used 8x1 multicolour and read the data from a buffer, so by changing the start address of the buffer you could scroll it. It used a 00001111 pattern in the background so it only moved the colours, not the pixels.

I've just got an 8x2 multicolour function working that uses a buffer with a variable starting point, and it's looped, so there are only four lines of unrolled code (one character row, then it loops). Although it's only 22 characters wide. I can do 24 wide, but that requires some top-border time to part-draw the initial attributes and free up the time it needs to manage the looping. The buffer can be any height and width, so you can scroll the colours in any direction just be changing the start address.
1 x

Ralf
Microbot
Posts: 121
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: Horizontal scrolling solutions #1457

Post by Ralf » Mon Nov 20, 2017 10:17 am

Some quick questions.

Do you copy both pixels and attributes to screen now or is it still 00001111 pattern?

Would it be hard to add moving sprites to this engine?
0 x

Joefish
Berk
Posts: 49
Joined: Tue Nov 14, 2017 10:26 am

Re: Horizontal scrolling solutions #1457

Post by Joefish » Mon Nov 20, 2017 8:39 pm

Depends on what I want to do.

For something like River Raid, I'd probably leave it with the 00001111 pattern so I can paint the scenery in 4x1 extra-wide blocky pixels and scroll it vertically at any speed instantly. Horizontally, you could have two colour buffers prepared, and swap between them to give the impression of a 4-pixel horizontal scroll. But mainly the advantage here is a smooth vertical scroll at little cost. You could try different pixel patterns, e.g. thin vertical lines, then do horizontal lines with 8x1 matching INK and PAPER colours to make a scrolling grid.

There's no reason why you can't have regular standard resolution sprites on top of this. You just have to erase them or paint over them with the background attributes again, and make sure instead of deleting their pixels you replace them with the background pattern (e.g. 00001111). Probably best not to try and pixel-mask them onto the background; just do a straight block copy. But you could maybe use transparent PAPER, or invert part of the sprite and give it transparent INK if it's right-hand edge is more exposed. But probably best to just have it bounce off or crash into anything too detailed!

For finer horizontal scrolling, you need to do what Hikaru has done, which is to repaint the pixels quickly with something lke Joffa's super-fast Cobra scroller in-between passes of the multicolour routine. With a buffer (or two copies of your multicolour routine) you can render the attributes to a hidden buffer on your first pass, then repaint the pixels, then switch the colours over to the prepared buffer instantly. You can do the sprites like that too; first the colours to a back buffer, then switch it in the instant you've rendered their pixels.
0 x

Hikaru
Berk
Posts: 48
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Horizontal scrolling solutions #1457

Post by Hikaru » Mon Nov 20, 2017 10:04 pm

Right, I remember that RR demo. Incidentally, I think I found a way to use non-black colors like green? for the sync marker area in aline, with artifacts kept to a fairly low amount (as sparse bits of BRIGHT for half the line). :roll:

Mint uses just one multicolor 'canvas' (data+code buffer) for everything. The canvas isn't looped so the attributes are updated the old-fashioned way by repainting them over, although in a somewhat complex manner, greatly cutting on the amount of data to process, as well as accomodating for the 'mc-paper 8x2 mode' backgrounds. Additionally, it doesn't touch the mc-attributes at all times but only at specific intervals while the camera is moving.
The method for multicolored sprites itself is mostly there on the paper. However, I found that the sort of sprites my immediate project uses aren't really suited for it. So this functionality will probably have to wait.
0 x

Post Reply