A.D.A. Amiga Demoscene Archive

move.b 3(a0),d0 ;get the blue i have reached so far
move.b 2(a3),d1 ;get the blue value i want to reach

why 2(a3) ? not RRGGBB in a3 ?

@cyf:
i just wrote my code on a paper and typed it here in the forum. I presume (and hope) that it is 3(a3) in my code and that i mistyped here in the forum. But i can't check right now (i'm at work). Ofcourse it should be 3(a3). Hmm... i'll check tonight. If it that is the problem, i'm going to punch myself with a hammer 4 times in a row.

Do you see any error in my logic? I know it isn't the best fade algo but what can you expect. Experience will hopefully teach me to do better. that's why it's important to start trying to code my own routines instead of copy paste everything and throw it together.

In any case, thanks for trying to help me out :)

I tested your code and it seems to work (buffer =0, color $040051 reached)

2 possibilities : fade in a buffer RRGGBB and copy RRGGBB in coplist RGB-RGB
or convert RRGGBB to RGB-RGB source palette and fade directly in coplist (the old fade routine works in this case)

My code pasted from my source. I left out the part where i write the RRGGBB to my copperlist but i'm sure this works. The only color i get is the end color (in this case ff blue) without any fading.

faio:
move.l #$00000000,(a0)
move.l #$000000ff,(a3)

moveq #0,d0
moveq #0,d1

;work on blue
move.b 3(a0),d0
move.b 3(a3),d1
cmp.b d1,d0
beq.w .blue_done
blt.w .blue_fade_in
sub.b #1,d0
bra .blue_new_value
.blue_fade_in:
add.b #1,d0
.blue_new_value:
move.b d0,3(a0)
.blue_done:
rts

d0=$ff because of sub.b #1,d0 at the first pass

$ff.B=-1, use .W = cmp.w d1,d0

(when i tested the code, i used $51 and $4, no $ff)

damn, i finally found it before i saw Cyf's post. I set up a little test system and the result of my compares was curious to say the least. Then i thought: does cmp.b treat my byte as unsigned 0 -> 255 or as a signed -128 -> 127 (or there about). So i used cmp.w and it worked.

So is this indeed the problem? Is it comparing signed values? And how can this be avoided?

by using bcs or bls instead of blt (bit carry set)

Hello!

I push up this thread to ask information about techinques for fading colors, from one palette to a destination palette.
I know basically two techinques, which I describe with algorithm

#1: so called "fake-fade"

for each step and each color
for each component
increment (or decrement) by 1 (or by a constant amount) the component
if component > (or <) destination value then component = destination value

#2: RGB-fade

for each step N and each color
for each component C
D = destination value - C ; difference
V = D*N/ Total Number of Steps +C ; V is the value used for this step

Algorithm #2 should be more accurate, because the transition of each component is uniformly distributed in the required number of steps.
However, in practice, sometimes produces ugly results due to the
truncation of the fractional part.
I am doing a fade of 12-bit colors with start color white = $FFF.
Let's say I have 2 pixel, close to each other, with destination values $768 and $879.
With algorithm #2, it happens that at step 2 of 16 pixels become
$EEF and $FEF while at step 3 of 16
$EEE and $EEE

So you see that 2 colors that at step 1 are the same ($FFF) become different at step 2 and again the same at step 3. This is ugly to see.
Is there some other algorithm (better than #1) which avoids such a problem?

z5, I can't really find any bugs in your routine, but find strange that you keep a0-data with 4bytes-per-color and then a1-data with 3bytes-per-color, so Blue is at offset 3 for a0-data and at offset 2 for a1-data. This unsymmetry may be related to the bugs

TheDarkCoder, maybe you should do rounding instead of truncation (trick from asterix/movement vector coding tutorials).

truncation:
muls.w d0,d1 ; d1 = bits 0123456789abcdef
asr.w #8,d1 ; d1 = bits 01234567, X flag = bit 8
rts

rounding:
moveq.l #0,d2
muls.w d0,d1 ; d1 = bits 0123456789abcdef
asr.w #8,d1 ; d1 = bits 01234567, X flag = bit 8
addx.l d2,d1 ; add 1 to d1 if X flag is 1
rts

it's "stupid question" time again. a0 points at my pallette.
move.b $ff 3(a0) => background is red
move.b $ff 2(a0) => background is green...

but why doesn't this work
move.w $ffff 2(a0) => background is mixture of red and green

And while we are at it. Why does a pallette of 256 colors has to be defined like this: ds.l 256*4.
Each color is 4 bytes, or 1 longword so i would have written ds.l 256? I assume that the *4 is actually in bytes but why the .l then?
And how do you define a pallette of 256 colors white for example?

You can define a white palette using the dcb.l directive (Define Constant Block), back in the days of (un)holy (master)seka this was known as blk. :) Contrary to ds.l you can specify a value the block should be filled with.
f.e.: dcb.l 256,$00ffffff would give you a white palette.
(dcb.l 256,-1 will to the trick as well and saves you some typing since the upper 2 bytes are not used for palette entries anyway).
Basically, what this does is the same as this:


REPT 256
dc.l $00ffffff
ENDR

The *4 thing I don't get since a normal aga palette is just one long per entry so a ds.l 256 is all you need.