using copper to change color every 8 pixels

[geldo79]

Hi,


i have a question concerning copper waits. If i want to change a color every 8 pixels, i can wait for a line, and use multiple move instructions. What i don't understand is: why do i have to do so many moves (see copper code), before i see the first effect on the left side of my screen? Ok, my screen has 16 pixel hidden space on the left and right side (352x256), but that would only explain 2 extra moves, not 13! And why are the changes not aligned on the bytes (starting at left most pixel). If you look at my sample image, the first green block is only 7 pixel wide, or at least only seven pixels can be seen.

    dc.w $2c07,$fffe
    dc.w $194
 

BG_C0:


    dc.w $305
        
    dc.w $194,$f00   ; next 13 moves are not seen on the screen
    dc.w $194,$0f0
    dc.w $194,$00f
    dc.w $194,$f00
    dc.w $194,$0f0
    dc.w $194,$00f
    dc.w $194,$f00
    dc.w $194,$0f0
    dc.w $194,$00f
    dc.w $194,$f00
    dc.w $194,$0f0
    dc.w $194,$00f
    dc.w $194,$f00
    
    dc.w $194,$0f0    ; from here the changes can be seen on screem
    dc.w $194,$00f
    dc.w $194,$f00
    dc.w $194,$0f0
    dc.w $194,$00f
    dc.w $194,$f00
    dc.w $194,$0f0
    dc.w $194,$00f

[a/b]

Because of horizontal blanking. From the copper's perspective, visible area typically starts at $81 (lores PAL, no overscan) and ends at $81+320=$(1)c1.
Look at http://amigadev.elowar.com/read/ADCD.../node02D4.html (those numbers are DMA slots, multiply by 2 to get "pixels", e.g. $e0 -> $1c0).

[geldo79]

That means it is not possible at all to let the color change start at the first pixel, and have 40 equally spaced bars of 8 pixel widths?

[ross]

Originally Posted by geldo79

That means it is not possible at all to let the color change start at the first pixel, and have 40 equally spaced bars of 8 pixel widths?

Why not?
Just set your DIWSTRT=$xx80 and first BPLCON1=$FF (I suppose you hide first 16px because of fine-scroll).

[geldo79]

Originally Posted by ross

Why not?
Just set your DIWSTRT=$xx80 and first BPLCON1=$FF (I suppose you hide first 16px because of fine-scroll).

But there is also an image in the background. This would also be shifted 1 pixel to the right?! That would not be what i want.

[ross]

Originally Posted by geldo79

But there is also an image in the background. This would also be shifted 1 pixel to the right?! That would not be what i want.

Actually 15 pixels.. But I still don't understand the problem.
If you have a scrolling background you certainly don't have a fixed image in the background (unless you're using dual-playfield, which you didn't mention).
And in any case you can adjust the position when writing data to the screen.
Unfortunately, without a general idea of what you want to do it is impossible to give precise advice, the copper code you posted does not report anything about the video settings or the viewing window or what will happen on the screen.

[geldo79]

Originally Posted by ross

Actually 15 pixels.. But I still don't understand the problem.
If you have a scrolling background you certainly don't have a fixed image in the background (unless you're using dual-playfield, which you didn't mention).
And in any case you can adjust the position when writing data to the screen.
Unfortunately, without a general idea of what you want to do it is impossible to give precise advice, the copper code you posted does not report anything about the video settings or the viewing window or what will happen on the screen.

Here's an image. In my game, there's a HUD where two green energy bars are shown. The color is changed every 8 pixels. But due to the misalignment of the color bars (they don't start at pixel 0 on the left), i can not have the two bars symmetrical to the center of the screen....(of course i can, but then the two bars look different). Here i had to shift one bar two let the two bars look identical. There is no scrolling background. The extra space on the left /right side is for bobs....without having to clip.

[ross]

Originally Posted by geldo79

There is no scrolling background. The extra space on the left /right side is for bobs....without having to clip.

Ok, nothing changes from what I said.
You simply 'move' the HUD to the previous word in memory and shift 15 pixels (or if you want to see it from the opposite direction, shift 1 pixel to the left).
It's just a question of no longer thinking about having the image aligned in memory and that on the screen it is 'one pixel first'.
Of course if you want to have colored and 'centered' columns made with copper

[a/b]

To put it simple, copper resolution is 4x lower than lores screen resolution. Copper cannot start changing the bg color at any pixel, so you have to align the rest.
Assuming 0-4 bitplanes, copper move takes 8 pixels and the start pixel can be every 4th pixel. Try $2c37, $2c39, ... to find the closest match, and the rest you will have to sort out by scrolling the bitmap with $dff102 as Ross mentioned, or adjusting the assets and baking in the scroll.

[Rock'n Roll]

to start a copper move sequence to change the color every 8px at DIWSTRT 0x80
the appropriate wait would be: (to avoid useless copper moves)

dc.w $vv3f,$fffe (horizontal waitpos. 0x3e), first color change at: 0x80
dc.w $0180,$0RGB

Copper color changes are only possible at even pixel positions.
either the screen or the superimposed image must be aligned.

And if you change the horizontal wait-position, only four different x-positions
are possible within 16 pixels, which corresponds to a 4 pixel accuracy.

[geldo79]

Originally Posted by ross

Ok, nothing changes from what I said.
You simply 'move' the HUD to the previous word in memory and shift 15 pixels (or if you want to see it from the opposite direction, shift 1 pixel to the left).
It's just a question of no longer thinking about having the image aligned in memory and that on the screen it is 'one pixel first'.
Of course if you want to have colored and 'centered' columns made with copper

Thanks. So this finally solved my problem:

        dc.w	$8E

DiwStart:

	dc.w	$2c80	
	dc.w	$90
	
DiwStop:

	dc.w	$2cc0	
	dc.w	$92
	
DdfStart:

	dc.w	$34		
	dc.w	$94
	
DdfStop:
	
	dc.w	$cc		 

	dc.w	$102
	
BPCON1:
	
	dc.w	$FF

[saimon69]

Originally Posted by Rock'n Roll

to start a copper move sequence to change the color every 8px at DIWSTRT 0x80
the appropriate wait would be: (to avoid useless copper moves)

dc.w $vv3f,$fffe (horizontal waitpos. 0x3e), first color change at: 0x80
dc.w $0180,$0RGB

Copper color changes are only possible at even pixel positions.
either the screen or the superimposed image must be aligned.

And if you change the horizontal wait-position, only four different x-positions
are possible within 16 pixels, which corresponds to a 4 pixel accuracy.

Can this be used for a grid of changing palette attributes? Like a PCHG from a column of 8 to the next? Is fast enough?

[Rock'n Roll]

With a Copper-Move sequence the color can be changed every 8px and the horizontal start of the
sequence can be positioned every 4px on the screen via the horizontal Copper wait.

RGB Plasma uses this copper property to change the colors every 8px and thus create dynamically moving images.

However, an entire color palette cannot be changed, but only one color register every 8px.

[saimon69]

So you cannot simulate an attribute grid like on the ZX spectrum -_-

[ovale]

Maybe is possible using 2 bitplanes. On bitplane 1 you always emit 0x00FF every 16 pixel. On bitplane 0 you draw monochrome images as usual. Then use Copper to change color 2,3 where bitplane 1 is 0x00 and color 0,1 where is 0xFF.

[AestheticDebris]

Originally Posted by ovale

Maybe is possible using 2 bitplanes. On bitplane 1 you always emit 0x00FF every 16 pixel. On bitplane 0 you draw monochrome images as usual. Then use Copper to change color 2,3 where bitplane 1 is 0x00 and color 0,1 where is 0xFF.

I don't think that would work still, the Spectrum can change 2 colours every 8 pixels and whatever you do that's going to be more changes than the Amiga can manage short of just using a 16 colour screen.

[robinsonb5]

Originally Posted by saimon69

Can this be used for a grid of changing palette attributes? Like a PCHG from a column of 8 to the next? Is fast enough?

On AGA machines perhaps you could do something using the BPLCON4 register?
(If you set up multiple palettes across the 256 colours, you can switch between them with a single copper move.)

[paraj]

Originally Posted by robinsonb5

On AGA machines perhaps you could do something using the BPLCON4 register?
(If you set up multiple palettes across the 256 colours, you can switch between them with a single copper move.)

If I'm not mistaken, you would need 512 palette entries for a really easy version, but something like this should work. I.e. before each block (of 8 lines), load the 32 color pairs that are used into a 64 color "bank". Every 8th pixel switch to bank that matches block while preparing colors for next 8 lines in next "bank" during hblank.


Wasn't something like this was discussed recently? Anyway, might make for fun challenge (something like, convert zx screen every frame and have it displayed properly).

[saimon69]

Originally Posted by paraj

If I'm not mistaken, you would need 512 palette entries for a really easy version, but something like this should work. I.e. before each block (of 8 lines), load the 32 color pairs that are used into a 64 color "bank". Every 8th pixel switch to bank that matches block while preparing colors for next 8 lines in next "bank" during hblank.


Wasn't something like this was discussed recently? Anyway, might make for fun challenge (something like, convert zx screen every frame and have it displayed properly).

I did proposed early, the idea was to have partially dynamic dual playfield coloring even though might create some color clash - useful for capcom-like games where different enemy color = different energy level

[chb]

IMHO an attribute grid could work with a limited palette of up to 8 colors each for foreground background (16 may work, too, but we are after that Speccy look after all ), using BPLCON4's XOR feature:

Set up a static 256 entry palette in a way that for all even indices, the color is bgcolor << 4, so e.g. color 0x00,0x02,..0x0E are set to bg-color 0, 0x10,0x12..0x1E to bg-color 1, and so on.

Then for all odd indices, the color is set to fg-color << 1, so 0x01,0x11,0x21..0xF1 are set to fg-color 0, 0x03,0x13,0x23..0xF3 are set to fg-color 1.

Then putting the bg-color <<4 || fg-color <<1 in the XOR-byte of BPLCON4 every 8 pixels selects the color combination; combined with a 8-line copper loop that should give you something like an attribute grid.


But even if the logic above is correct, which isn't a given (I just came up with that without testing it), it may not work in practice - IMHO it is not a given that changes to BPLCON4 take effect immediately, the might do so only every 16 pixels, or even more in higher fetch modes. DNK if this is documented somewhere.