Colour fading?

[h0ffman]

One of the things I'd like to do soon is some colour fades, for example black to the colour of a logo / white to the colour of a logo.

I think they way to move forward would be to have two palletes, source colours and destination colours. You then loop through each colour, split out the 3 x 4bit colours, add 1 to each and compare each against the destination colour which will build up the current colour. Loop through the routine $f times to ensure all colours reached destination.

Just wondering if this is a good way of doing it, or if there is a quicker / better method.

[StingRay]

Sounds perfectly fine to me. If you can live with constant fading speed that is.

[Zetr0]

@h0ffman

thats pretty much how I used to do it... I found a better way was to have 3 pallets

A Primary pallet, A secondary Pallet and a modifyable Pallet.

this way - when I did fade and swaps I would always have a master pallet to fall back on.

For timing - I used a counter/controller based on skipping the wait of the vertical blank, this way I could have fast or slow transisitions pending number of skips.

[StingRay]

Originally Posted by Zetr0

thats pretty much how I used to do it... I found a better way was to have 3 pallets

A Primary pallet, A secondary Pallet and a modifyable Pallet.

this way - when I did fade and swaps I would always have a master pallet to fall back on.

Why would you need 3 palettes? The original (= source) palette is NEVER modified in the fade routine!

[Zetr0]

@stingray

I had a

Source (live pallet)
Dest (the pallet I wanted to get to)
Static (the Pallet I need to go back to after dest transitions)

At one point I would have a couple of Destination Pallets to transition to - kinda brute force in a way and a little more memory than should be needed for most single colour fade transitions - but at one point I would have an anim running with fading back and forground colours - I have to admit I was a strange kid back then =)

I should mention I was doing all this in C (Dice/Lattice) not ASM, but if memory serves me I tweeked the hell out of the routine after I compiled it to ASM.

I should also point out that I did write a IFF/ILBM picture loader viewer that would fade in and out and then grab the next pallet... .... whoa.... this was nearly 15 years ago.... I wonder if I still have that code?

[h0ffman]

Thanks for the feedback guys, good to know I had the right idea.

[pmc]

Stumbled across this thread today and as I had ten minutes to spare to I knocked up a quick stab at a palette fader.

It'll cross fade one palette to another so could also be used to fade in or fade out as required depeding on how the current and destination palettes are setup.

[phx]

The algorithm discussed in this thread is quite simple and it works, but it doesn't look as nice as it could.

Imagine a situation with an RGB colour like $f88 (pink). After half of your colour fading steps it will be $888, which is plain grey! With 50% intensity it should better be $844, don't you think?

That makes the algorithm a bit more complicated and involves some multiplications and divisions, but this will always be fast enough for such a simple effect and the result will be worth it.

[Lonewolf10]

I briefly had a small routine (not used) in my demo I'm working on... hang on...

*searches through the depths of my harddrive*

Ah ha! Here we are:

sprite_fade:
	movem	d0-d7/a0-a6,-(sp)
	lea.l	bplcon+46(pc),a0	;start of sprite colours (COLOR17)	
	addq	#4,a0
	move.w	(a0),d0			;old value -> d0
	sub.w	#$100,d0		;fade colour
	move.w	d0,(a0)			;new value (d0) -> copper3 COLORreg
	move.w	4(a0),a1		;fade next color
	addq	#4,a0
	move.w	(a0),d0
	sub.w	#$111,d0
	move.w	d0,(a0)
	move.w	8(a0),a1		;fade next color
	addq	#4,a0
	move.w	(a0),d0
	sub.w	#$000,d0
	move.w	d0,(a0)
	addq	#4,a0
	moveq	#2-1,d1
	move.l	COLOR21,a0
	lea.l	sprcol+2(pc),a0
sprite_fade_b:
	sub.w	#$100,(a0)
	addq	#4,a0
	sub.w	#$111,(a0)
	addq	#4,a0
	dbra	d1,sprite_fade_b	;loop
	movem	(sp)+,d0-d7/a0-a6
	rts				;all sprite colours faded a little

It was going to be used to fade sprite colours (stored in my copperlist) to black. It fades out 2 (3?) colours with different intensities. First one fades out red only, 2nd fades red,green and blue out and 3rd one currently fades nothing!

It works fine most of the time, but if for example blue reaches 0 too soon, then deducting $111 will turn blue back to $F and fade green twice as fast on that occasion. I think that's the reason I didn't use the code. Is there a workaround to this?


Regards,
Lonewolf10

[pmc]

Originally Posted by phx

Imagine a situation with an RGB colour like $f88 (pink). After half of your colour fading steps it will be $888, which is plain grey! With 50% intensity it should better be $844, don't you think?

In this situation, my posted routine would actually fade colour $0f88 (pink) to $0800 (moderate red) at the halfway stage towards fading the colour to $0000 because I fade the individual red, green and blue colour nibbles one step towards the target colour each iteration and not at all once they reach it but I take your point, a nice even "halfway" would be the ideal.

I'll do some testing of alternate methods when I get some time.

Thanks for the advice phx, appreciated.

[Lord Riton]

You just need to look for the highest difference of the 3 rgb components ( you call them nibbles). This will be the number of loops you will have to do to get from source A to dest B color.

Add 1 to that highest color component each loop, and calculate it for the 2 others if they need to get one added too or not, and do it

Let's say A is the highest difference, and so also is the number of loops to do.
B and C are the other 2 valours.
A1 = source red component, A2 = destination red component.
B1 = source green component, B2 = destination green component.
C1 = source blue component, C2 = destination blue component.


this will give something like that, (in some basic language):

for i=0 to A
  ActualA = integer( A1+ i/A * (A2-A1) )
  ActualB = integer( B1+ i/A * (B2-B1) )
   ActualC = integer( C1+ i/A * (C2-C1) )
 
"  Store your color here, with your rgb components beeing ActualA, ActualB and ActualC"

next I

[pmc]

Thanks for that little explanation Lord Riton, appreciated.

Oh, just for interest, I call the individual red, green and blue colour components nibbles because a nibble = 4 bits or half a byte.

[Photon]

You can also do normal fade to any color by precalcing a 4K word "next fade-step color" table. Fade out comes by simply using the $0RGB color << 2 as 'linked list jump ptr', for fade in you need to do the fadeout and store n palettes beforehand, where n is the (fixed) number of fade-steps you want. It's fast, so it can be used for lotsacolors like coppershades, but it still requires a bona fide FadeRGB routine, so it takes a few extra bytes of code.

[korruptor]

I've not written (or used) one for a while, but from memory, what I did was look at the palette in the copper list and a dest palette that I wanted to get to. Then created a 32 entry table, each entry of which was the value to inc or dec the colour in the copper list by, each frame.

That was fine for quick fades, but I've been meaning to write something a bit better so I could get longer transitions. Maybe pushing all the colours into fixed point so fractional fading could happen over a number of frames to smooth it out a bit more.

Dunno, something to play about with.

[Photon]

I made a high precision fade routine back in 1990 which was pretty simple, it used not $0rgb colors but bytes, $r0, $g0, $b0 and faded them to the same type of palette or to the copper (translating to $0rgb with some simple shifts). If you're bent on calculating the fade there's nothing to stop you from doing the same with dc.w r,g,b though. You can still do high-precision with tables, but it's trickier to get the tables small (or 'not huge').

[mcgeezer]

Apologies for bringing up a thread that is nearly 8 years old but this was the only thing I could find around doing colour fading.

I need to do some very fast colour fading and was hoping I could get some example ideas.

I've been thinking about just pre-calculating the colour values over a set number of frames, so for a 1 second fade out i lookup the colour values in a tangent table over 50 frames.

With the Adjacent side being the number of frames and values (intensity) being the Opposite sides in the triangle.

Would this work? But more importantly is there a much simpler way to do it?

For the reasons PHX stated above I don't simply want to just do an add/sub $111 on the palette.

Geezer

[ross]

Originally Posted by mcgeezer

Apologies for bringing up a thread that is nearly 8 years old but this was the only thing I could find around doing colour fading.

I need to do some very fast colour fading and was hoping I could get some example ideas.

I've been thinking about just pre-calculating the colour values over a set number of frames, so for a 1 second fade out i lookup the colour values in a tangent table over 50 frames.

With the Adjacent side being the number of frames and values being the Opposite sides in the triangle.

Would this work? But more importantly is there a much simpler way to do it?

For the reasons PHX stated above I don't simply want to just do an add/sub $111 on the palette.

Geezer

Hi Geezer, there is a context somewhere on board about it.
(with also my code in it)

If I find it, I'll post the link.

[EDIT]
found: http://eab.abime.net/showthread.php?t=86561

[mcgeezer]

Originally Posted by ross

Hi Geezer, there is a context somewhere on board about it.
(with also my code in it)

If I find it, I'll post the link.

[EDIT]
found: http://eab.abime.net/showthread.php?t=86561

Brilliant - cheers Ross!