A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in




log in with SceneID


Demos Amiga Demoscene Archive Forum / Coding / coding tutorial: colors
 Page:  ««  1  2  
Author Message
#1 - Posted: 5 Jan 2005 12:24 - Edited
Reply Quote
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 ?
#2 - Posted: 5 Jan 2005 12:41 - Edited by Admin
Reply Quote
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 :)
#3 - Posted: 5 Jan 2005 13:31 - Edited
Reply Quote
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)
#4 - Posted: 5 Jan 2005 18:12 - Edited by Admin
Reply Quote
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.

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
add.b #1,d0
move.b d0,3(a0)
#5 - Posted: 5 Jan 2005 19:06 - Edited
Reply Quote
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)
#6 - Posted: 5 Jan 2005 20:37
Reply Quote
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?
#7 - Posted: 5 Jan 2005 20:55 - Edited
Reply Quote
by using bcs or bls instead of blt (bit carry set)
#8 - Posted: 8 Jul 2005 16:28
Reply Quote

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?
#9 - Posted: 28 Oct 2005 22:02
Reply Quote
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
#10 - Posted: 28 Oct 2005 22:11
Reply Quote
TheDarkCoder, maybe you should do rounding instead of truncation (trick from asterix/movement vector coding tutorials).

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

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
#11 - Posted: 19 Dec 2005 12:11 - Edited
Reply Quote
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?
#12 - Posted: 20 Dec 2005 17:09
Reply Quote
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

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.
 Page:  ««  1  2  

  Please register a new account or log in to comment





A.D.A. Amiga Demoscene Archive, Version 3.0