Colour fade

[elliot]

Okay so there was a thread recently about SOTB, it reminded me of doing fades (i.e. from a picture to black). I never got it right, I just subtracted $111 from all the colour registers. The problem with this is that when the colours got close to black you would get a of the screen detail turning to say a blue. It kind of looked okay but it always bugged me as it was not right.

Is there a simple code to reduce each colour register so the colours would stay near there original colour just darker? i.e. I am thinking a percentage of each RGB value.

I know for the STE this is a bit trickier but the principle is the same.

[thomas3]

Hiya,

Basically, use a logical AND to isolate each component of the RGB, adjust these as you wish, and then recombine. This allows you to ensure you don't flip one of the colour values under 0.

What language do you want to do this in?
Cheers,
Tom.

[Total Eclipse]

Hiya,

Basically, use a logical AND to isolate each component of the RGB, adjust these as you wish, and then recombine. This allows you to ensure you don't flip one of the colour values under 0.

What language do you want to do this in?
Cheers,
Tom.

I don't think that he's talking about colour values going negative, rather the fact that if you have, say a colour value of $713 (so a kind of pink) and you fade by subtracting $111 each time, you end up with $602, $501, $400 (at which point it's no longer pink, rather a dark red), $300, $200, $100, $000.

What I think the OP is asking for is a fade that's more like $613, $512, $402, $302, $201, $101, $000, so the pink hue is maintained until the colour is almost black.

[Zippy]

This is how I did it for the logo fade up/down at the start of my fullscreen intro, enter with A0 pointing at the pallete you want to use.

You can see the effect in action at the start here:
https://www.youtube.com/watch?v=rgwd3ZWMK9Y

Code: Select all

fade_up	moveq #0,d7			;initial max R value
	moveq #0,d6			;initial max G value
	moveq #0,d5			;initial max B value
	moveq #7,d3			;8 fades (from 0 to 7)
	move.l a0,-(sp)			;save pallete pointer
.2	moveq #15,d4			;16 colours
	move.l (sp),a0			;get pallete pointer
	lea $ffff8240.w,a1		;point to screen pallete
	bsr v_sync			;wait
	bsr v_sync			;for
	bsr v_sync			;it !!
.1	move.w (a0)+,d0			;get a colour from pallete
	move.w d0,d1			;copy
	move.w d0,d2			;copy
	and.w #$700,d0			;split R value
	and.w #$070,d1			;split G value
	and.w #$007,d2			;split B value
	cmp.w d0,d5			;Is fade value higher than R value?
	bgt.s .3
	move.w d5,d0			;If not, make colour = fade value
.3	cmp.w d1,d6			;Is fade value higher than G value?
	bgt.s .4
	move.w d6,d1			;If not, make colour = fade value
.4	cmp.w d2,d7			;Is fade value higher than B value?
	bgt.s .5
	move.w d7,d2			;If not, make colour = fade value
.5	or.w d2,d1			;merge G and B
	or.w d1,d0			;merge R, G and B
	move.w d0,(a1)+			;display RGB value
	dbf d4,.1			;next colour
	add.w #$100,d5			;fade up 1 R value (max)
	add.w #$010,d6			;fade up 1 G value (max)
	add.w #$001,d7			;fade up 1 B value (max)
	dbf d3,.2			;next fade
	tst.l (sp)+			;tidy stack
	rts

fade_dn	move.w #$700,d5			;see comments for fade_up
	move.w #$070,d6			;goes from 7 to 0 in steps of 1,
	move.w #$007,d7			;instead of 0 to 7 in steps of 1 !!
	moveq #7,d3
	move.l a0,-(sp)
.2	moveq #15,d4
	move.l (sp),a0
	lea $ffff8240.w,a1
	bsr v_sync
	bsr v_sync
	bsr v_sync
.1	move.w (a0)+,d0
	move.w d0,d1
	move.w d0,d2
	and.w #$700,d0
	and.w #$070,d1
	and.w #$007,d2
	cmp.w d0,d5
	bgt.s .3
	move.w d5,d0
.3	cmp.w d1,d6
	bgt.s .4
	move.w d6,d1
.4	cmp.w d2,d7
	bgt.s .5
	move.w d7,d2
.5	or.w d2,d1
	or.w d1,d0
	move.w d0,(a1)+
	dbf d4,.1
	sub.w #$100,d5
	sub.w #$010,d6
	sub.w #$001,d7
	dbf d3,.2
	tst.l (sp)+
	rts

v_sync	movem.l d0-a6,-(sp)		;save all registers
	move.w #37,-(sp)		;wait sync
	trap #14
	addq.l #2,sp
	movem.l (sp)+,d0-a6		;restore and exit
	rts

[thomas3]

I don't think that he's talking about colour values going negative, rather the fact that if you have, say a colour value of $713 (so a kind of pink) and you fade by subtracting $111 each time, you end up with $602, $501, $400 (at which point it's no longer pink, rather a dark red), $300, $200, $100, $000.

What I think the OP is asking for is a fade that's more like $613, $512, $402, $302, $201, $101, $000, so the pink hue is maintained until the colour is almost black.

Hiya, sorry, I wasn't clear enough. The challenge in any routine like this is not going under 0. Once this is sorted, you're laughing and just need to work out how much to take off each value.

Elliot, is it that you're struggling to know how much to decrement each value by?
You just need to use fractions - so either floating point (BASIC) or fixed point (assembly) adjustment to each of R, G and B, which are then each converted to integer to work as an RGB value.
If you're using STe colours, you need a look up table or array to capture the odd $1,$8,$2,$9,$3,$a etc increment pattern. You can then index this via your floating/fixed point fraction converted to an integer.

Try it in STOS.

[mikro]

Is there any reason why you can't prepare palette values in a lookup table? Then you can choose any slope you like, not only constant addition/subtraction but also e.g. linear interpolation with a fixed number of steps.

[AnthonyJ]

rather than scaling the RGB equally, you'd likely get better performance by switching the RGB values into a different colourspace, such as HSL or YUV, scaling just the Luma, and then converting back to RGB (I guess you definitely will want a LUT if doing that!)

However ultimately with the example of $713, it's going to clip both the G and B to 0 very quickly which will distort the colour, and that's just an unfortunate effect of having only 3-bits per channel.

[elliot]

Elliot, is it that you're struggling to know how much to decrement each value by?

Yes exactly. So $713 the 1 needs to be 1 for most of the 7 decrements so you still have a colour which is somewhat the colour you started with. If you just decrement you will end up with $400 at some point which is just a dark red. Thinking about it doing a percentage decrement will also end up with other strange consequences, e.g you will end up at some point with something like $511 which is not the same colour.

[Zippy]

With the above code $713 would fade to $613, $513, $413, $313, $212, $111, $000 , so the shading gets worse as it gets darker but it's harder to see then anyway. It looked good enough to me, but then I never claimed to be a good demo coder.

[thomas3]

Yeah exactly - with 7 colour indices this is probably about as good as you'd get.

@elliott: without coding it out, I imagine an approach that uses fractions would probably give a fade such as: $713, $613, $512, $402, $301, $201, $100, 0. Which looks sensible?

[elliot]

Yeah I can see that the colour resolution is not so great, even on the STE. I wonder if there are little benefit of making it so complex.

[thomas3]

That would definitely be my view, especially as this isn't really perceptible at 50fps or even 25fps.

I use an approach similar to Zippy's in my own demos and I've never had a sense of it being problematic really.