CustomColors - how many times can I switch the palette?

[Marle]

Hiya,

I have been experimenting with the CustomColors command and the Display Library.

I don't know if I am using it right but the documentation is a bit vague!

As far as I can work out, I can switch out the palette every 8 scanlines/y pixels on OCS/ECS Amiga displays.

So I thought write a simple example to display 4 colours on a 1 bitplane screen.

I can get it to switch the colour once, but not any more after that, it appears that whatever the last CustomColors command is the one that sticks.

I don't quite understand what CCOffset is, I assume it stands for Custom Copper Offset?

BitMap 0,320,200,1

InitPalette 0,2
InitPalette 1,2
InitPalette 2,2
InitPalette 3,2

PalRGB 0,1,0,0,15 ; Blue
PalRGB 1,1,15,15,15 ; white
PalRGB 2,1,15,0,0   ; red
PalRGB 3,1,0,15,0   ; Green

Use BitMap 0

Cls 1

InitCopList 0,44,200,$401,8,2,8

BLITZ

CreateDisplay 0
DisplayPalette 0,0
DisplayBitMap 0,0

CustomColors 0,0,80,1,0,2 ; change to white 80px down

CustomColors 0,1,140,2,0,2 ; change to red 120px down

CustomColors 0,2,160,3,0,2 ; change to green 160px down

While Joyb(0)<>1
  VWait
Wend

End

[Coagulus]

I think i had the same problem. So for changing 1 colour many times I used the DisplayRainbow command and edited the palette. Got a nice few copper bars bouncing around using that.

[Daedalus]

I haven't actually used that command myself, however I think your custom space isn't right. The documents say 2+numcols for ECS - if you're changing a 4-colour palette, that's 6. You have 8, which is enough for one instance of the command, but the Custom[...] commands need space *per command*, so you should have 18 for three palette changes.

Now, as I said, I haven't tried it (but will when I get home...), so it could also be a case that it's simply limited to a single palette change per frame. As Coagulus points out, the DisplayRainbow command can be used to change a single pen multiple times during the frame, so is possibly a better approach for your particular example. Bear in mind you can't mix Custom[...] and Display[...] Copper commands, it's one or the other.

Edit: I'm not sure either what the CCOffset parameter is, but my guess would be the offset in the custom copper instructions space. So, with the first instruction using the first 6 bytes (0-5), the first instruction would be at CCOffset 0, the second at CCOffset 6 and the third at 12. But again, I'm just guessing.

[Marle]

Thanks guys!

The idea is with this one I don't actually want to create that traditional copper rainbow effect as in say Robocod 2 or Turrican 2, but more to subtly adapt the palette on the screen, it's only an experimentation at this stage in any instance.

So I made some progress, and have it working displaying 8 colours on a 2 colour screen, but unfortunately with my A600 in for recapping and a bit of TLC I am using FS UAE so I don't know how accurate it is. The result graphically is attached, the code is here:

BitMap 0,320,200,1 ; 1 bitplane, so only 2 colours...

InitPalette 0,2

PalRGB 0,0,15,15,0 ; yellow
PalRGB 0,1,7,7,0 ; dull yellow

Use BitMap 0
Boxf 160,0,320,200,1
Boxf 0,0,160,200,0 ; bear in mind this draws to the bitmap
                   ; so colour changes will affect this
                   ; almost like a multiply effect in Photoshop

InitCopList 0,44,200,$401,8,2,12

BLITZ

CreateDisplay 0
DisplayPalette 0,0,0
DisplayBitMap 0,0,0,0

PalRGB 0,1,15,15,15 ; white
PalRGB 0,0,7,7,7 ; grey
CustomColors 0,0,48,0,0,2 ; change (update) palette 48px down

PalRGB 0,1,15,2,3 ; red
PalRGB 0,0,7,1,2 ; dull red
CustomColors 0,4,96,0,0,2 ; change to reds 96px down

PalRGB 0,1,15,0,15 ; cadbury purple
PalRGB 0,0,10,0,10 ; kickstart purple
CustomColors 0,8,144,0,0,2 ; change to purple 144px down

VWait

While Joyb(0)<>1
  VWait
Wend

End

So the problems, it seems no matter what I do there appears to be some pixels added to the left of the screen, so if you draw say Boxf 0,0,320,200,1 you get the second attachment? It's like the display is wider than 320 pixels but won't let you draw in that area?

Secondly the above code whilst it works, whilst the Y pos is set to 44 in the InitCopList as everything suggests, it leaves 2 lines of odd artefacting at the top of the screen when using the CustomColors?

Or is this what is meant by you can't mix and match Display... and Custom... commands. If that's the case - how do you display a bitmap and use these commands?

I tried the DisplayRainbow command and DisplayRGB but kept on getting not enough copper space no matter what I tried. What a flying start!

[Daedalus]

Ah, no the commands you can't mix are the DisplayRainbow-type commands that add Copper instruction per line of the display. The normal DisplayBitmap, DisplaySprite etc. commands are fine to mix. I don't really know what the corruption is at the top, but possibly just an artifact of the emulation or the chipset that would normally be in the overscan region. Do those lines go away if you set the Y position to 40?

The bar down the side in the second image I think is because you only have 2 colours available - background (colour 0) and colour 1. The background extends beyond the edges of the display into the overscan areas, which you can't really draw on without additional tricks. Like the extra grey around the edges of the Workbench screen.

DisplayRainbow and DisplayRGB need the CustomCops argument of InitCopList to be negative, so if you calculate that the command needs 6, then you need to give -6 as the argument. This might be why you're getting the insufficient space error.

[Marle]

If I set the Y position to 26 they go away, but anything above that and they appear. I guess it probably is an emulation artefact perhaps and the yellow extending into the overscan on 1 bpp screen makes sense.

I'll have another play tonight.

Thanks for the heads up on the negative values...I would never in a million years guessed it had to be negative!

I may not end up using these things but it could be useful so handy to get an idea of what is possible before planning a whole game around functionality that isn't possible!

[Marle]

Ok after a bit of playing around I found the artefacts at the top of the screen seem to come from not setting the coplist flags to include smooth scrolling. So adding $10 solved that.

The extra left border was indeed overscan.

There's something weird about drawing a line from 0,0 to 319,199 it's almost like it's lopping off the top left corner of the line oddly enough... If you draw to 320,200 it seems to go off screen i.e. at x = 320, the line only draws to y=199 I guess... Bit bizarre...

Anyway here's the code, 2 bitplane screen with 13 colours. Ugly as sin but a good proof of concept

Whether I need to use any of this I don't know but it's handy to know these things in advance of starting artwork.

My next test will be colour cycling to see what effects I can get from that to potentially mimic wind blowing through leaves on a tree or subtly changing the shadows on buildings to mimic light.

Here's the source for the ugly as sin thing though

BitMap 0,320,200,2 ; 2 bitplane, so only 4 colours...
InitPalette 0,4

PalRGB 0,0,0,0,0
PalRGB 0,1,15,15,0 ; yellow
PalRGB 0,2,7,7,0 ; dull yellow
PalRGB 0,3,0,15,0 ; greeeen

Use BitMap 0

Cls 1
Box 5,5,315,195,0
Boxf 30,30,290,170,2

InitCopList 0,44,200,$12,8,4,18

BLITZ
VWait 100

CreateDisplay 0

DisplayPalette 0,0,0
DisplayBitMap 0,0,0,0

PalRGB 0,1,15,15,15 ; white
PalRGB 0,2,7,7,7 ; grey
PalRGB 0,3,0,15,10 ; ?
CustomColors 0,0,48,0,0,4 ; change (update) palette 48px down

PalRGB 0,1,15,2,3 ; red
PalRGB 0,2,7,1,2 ; dull red
PalRGB 0,3,0,7,15 ; hmm?
CustomColors 0,6,96,0,0,4 ; change to reds 96px down

PalRGB 0,1,15,0,15 ; cadbury purple
PalRGB 0,2,10,0,10 ; kickstart purple
PalRGB 0,3,0,0,15 ; blue
CustomColors 0,12,144,0,0,4 ; change to purple 144px down

Line 0,0,319,199,3

VWait

While Joyb(0)<>1
  VWait
Wend

End

[Daedalus]

Great that you're steadily making progress Enabling the smooth scrolling flag does lose a pixel or two from the left of the screen unfortunately. It's because smooth scrolling needs an extra pixel to scroll through for the quarter-pixel parts. For example, if you scroll left half a pixel, your display would now be 321 pixels wide as the other half pixel gets shown at the other end too. So this is masked by slightly narrowing the display.

Whatever mechanism is used for that masking (presumably delaying the fetch slightly), might also be covering up the unwanted rows at the top as a side effect. I wonder if an alternative way around that might be to set a black palette and only set the other colours at position 0, thus rendering the extra lines invisible? Might be worth a try...

[Marle]

Oh that's ok then, I don't mind losing screen width so long as there is a reason for it. I just was scratching my head why a line from 0,0 appeared to be at 0,1 effectively!

I shall try that with the palette too, hopefully I'll have my A600 motherboard back this week so I can try this out on the real deal. I'm sure UAE is pretty good these days but there is something about seeing what it does on real hardware (admittedly through a Scart to HDMI converter box)

[Daedalus]

Absolutely, WinUAE is a phenomenal bit of software, but there are still small areas and edge cases where the emulation behaves slightly differently to real hardware. In particular, some AGA features like independent quarter-pixel scrolling on dual playfields, fetch-mode corruption (on real hardware, not on UAE) and I vaguely remember some difference with sprite palettes too. So it's always good to see things running on real hardware in case what you're seeing is a product of the emulation or the chipset itself.

And of course the extra fuzzy feeling of your software running on the real thing