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
Cyf
Member
#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 ?
z5_
Member
#2 - Posted: 5 Jan 2005 12:41 - Edited by Admin
Reply Quote
@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 :)
Cyf
Member
#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)
z5_
Member
#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.

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
Cyf
Member
#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)
z5_
Member
#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?
Cyf
Member
#7 - Posted: 5 Jan 2005 20:55 - Edited
Reply Quote
by using bcs or bls instead of blt (bit carry set)
TheDarkCoder
Member
#8 - Posted: 8 Jul 2005 16:28
Reply Quote
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?
winden
Member
#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
winden
Member
#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).

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
z5_
Member
#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?
StingRay
Member
#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
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.
 Page:  ««  1  2  

  Please register a new account or log in to comment

  

  

  

 

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