Advice on copperlist for borders

[MrD]

Hello!

Here's a picture of a naff game I'm writing for the A500. It's Tractor Beam mixed with Gravity Force 2.



My lousy-looking gradient background scrolls along with the screen (but at a different rate) so my game has to edit the copperlist every frame to put the markers at the right place.

If I simply check for the beginning of each band and set the COLOR00 there, the gradient extends off the sides of the screen and into the border area (which looks kinda messy). My idea was to make a copperlist that sets the border colour at the start and end of each line by checking for the edges of the 'visible bit-planey area'. As you can see, I've... kind of done that. There's a pixel of background colour sticking out either side of the tiles, but I think that's the closest I can get it.

Am I missing a really obvious different way to make the borders of the screen outside the bitplaney-area a specific colour?

The bottom of the screen is a reet mess because my copperlist isn't handling the bottom lines correctly yet.

Am I right in thinking that to do things on lines over 255, you have to insert a wait like $ffdf,$fffe before that part of the copperlist? Is that a single wait separating 'before' and 'after', or additional waits before every wait?

And is there a lower vertical limit to how far I can go with the copperlist?

[kamelito]

You should maybe use another color than the background one.
As you don't seems to use a lot of colors you can do this in dual playfield mode.
That way you don't need horizontal copper trick if your screen is not in overscan.

Kamel

[Leffmann]

If you f.ex have a 16 color screen just make COLOR00 and your borders black like Kam says, and draw your background in color 15 instead, that's the usual solution on OCS.

There is no vertical limit for the Copper, it will keep running the whole length of the display, and when the vertical blank occurs and we start over at line 0 the Copper will read program pointer 1 again and continue from there.

The problem is that since we only have 8 bits to compare against the lower 8 bits of the actual vertical position, we have to think of the display as segments of 256 lines, and to issue wait-instructions past line 255 we have to wait until we've crossed over from line 255 to 256, or from 511 to 512 etc.

The horizontal position stops at $E2 so typically you put $FFE3FFFE in your program, and it works because since we're right at the end of line 255, we will have crossed over to line 256 before the Copper will execute the next instructions. Other methods for delaying work too, there's nothing special about this wait-instruction, we could f.ex wait for line 254 and just insert lots of move-instructions to delay until line 256 as well.

[MrD]

Originally Posted by kamelito

You should maybe use another color than the background one.
As you don't seems to use a lot of colors you can do this in dual playfield mode.
That way you don't need horizontal copper trick if your screen is not in overscan.

Kamel

Of course! This is exactly the kind of really obvious thing I was looking for.

Thank you both.


Boom!