Optimized Alpha-Blending in asm?

[Vot]

Originally Posted by ags

well, we found a way to take the merged background color, if it is black, into account and output nevertheless a correct image. I used both the dtimage.library and the pngalpha.library and applied the alpha info onto the rgb info. Of course this is an overhead. Thus i am now working with peterk on a custom png decoder for my selfmade gui engine. I am also thinking about implementing it as a new library with open source. Noone should have problems with this task anymore.

👏👍

[AGS]

I am sorry but my Browser does not show the chars of your reply correctly. The only thing I see are two Placeholders for unicode-characters, one reading "01f 44f" and the other "01f 44d".

[Lonewolf10]

Originally Posted by AGS

I am sorry but my Browser does not show the chars of your reply correctly. The only thing I see are two Placeholders for unicode-characters, one reading "01f 44f" and the other "01f 44d".

I have the same issue. Are you using Firefox (3.6.22) like me?

[AGS]

My OS is Ubuntu Linux and my Firefox is versioned 29.0.

[Franchute13]

Work fine here. Windows 8 - Firefox 28.0
http://www.subeimagenes.com/img/sin-titulo-1071976.jpg

[AGS]

Probably that are rather new special chars only available in Windows. Thanks for the Translation.

[Mrs Beanbag]

Originally Posted by AGS

But d3 is my 255 value.

it doesn't matter, we're not using it anymore

Originally Posted by AGS

I mean, I again cannot see a difference wether I use spl, smi or none of the two. How do I know, it is correct?

well as i say the maximum possible difference is only 1, you would need a very good monitor to see the difference.

[AGS]

PeterK figured out that the spl and following lsr #8 eliminate each other. spl sets the low byte to either 0 or $ff and the lsr vanishes these 8 bits. So it really makes no difference.

[Leffmann]

Originally Posted by Mrs Beanbag

@Leffman you can replace x/256 by (x+128) >> 8 for correct rounding

Almost With integer arithmetic you always round towards 0, so you would have to add 255, and only when you have a negative operand, but it can be done branch-less with a couple of shifts and an add.

[Mrs Beanbag]

Originally Posted by Leffmann

Almost With integer arithmetic you always round towards 0, so you would have to add 255, and only when you have a negative operand, but it can be done branch-less with a couple of shifts and an add.

but that would make 1/256 = 1, i don't know why you would want that. Rounding to the nearest int, (128..256)/256 = 1 but (0..127)/256 = 0.

If you always want to round down, no adding is necessary, the problem there is it is not symmetric around zero, you might prefer to round negative numbers up instead.

[Leffmann]

With two's complement integer arithmetic we always want to round towards 0, so we only add 255 if we have a negative operand, and both -1/256 and 1/256 will become 0.

[Mrs Beanbag]

well you might always want to round towards 0, personally i find rounding to the nearest int quite pleasing

[Vot]

Originally Posted by AGS

I am sorry but my Browser does not show the chars of your reply correctly. The only thing I see are two Placeholders for unicode-characters, one reading "01f 44f" and the other "01f 44d".

Sorry they are emjoi charset characters..

[AGS]

Ok, here is the pngflux.library to load and draw PNG images w/ alphachannel support:

http://eab.abime.net/showthread.php?t=74927

[AGS]

@Mrs Beanbag

Is this good? We multiply alpha with 257 and then divide by 65536 in a swap.

calc_pixels    ; apply ARGB data onto RGB data

        moveq    #0,d0            ; image
        moveq    #0,d1            ; screen
        moveq    #0,d2            ; alpha
        move.w    #255,d3

.loop        move.b    (a0)+,d2        ; get alpha value
        beq    .skip            ; full transparency?

        cmp.b    d3,d2            ; full opaqueness?
        beq    .copy

        move.b    d2,d0
        lsl.w    #8,d2
        add.b    d0,d2

        moveq    #0,d0

        move.b    (a0)+,d0
        move.b    (a1),d1
        sub.l    d1,d0
        muls.l    d2,d0
        swap    d0
        add.w    d1,d0
        move.b    d0,(a1)+

        moveq    #0,d0

        move.b    (a0)+,d0
        move.b    (a1),d1
        sub.l    d1,d0
        muls.l    d2,d0
        swap    d0
        add.w    d1,d0
        move.b    d0,(a1)+

        moveq    #0,d0

        move.b    (a0)+,d0
        move.b    (a1),d1
        sub.l    d1,d0
        muls.l    d2,d0
        swap    d0
        add.w    d1,d0
        move.b    d0,(a1)+

        dbf    d7,.loop
        rts

.skip        addq.l    #3,a0
        addq.l    #3,a1
        dbf    d7,.loop
        rts

.copy        move.b    (a0)+,(a1)+
        move.b    (a0)+,(a1)+
        move.b    (a0)+,(a1)+
        dbf    d7,.loop
        rts

[Mrs Beanbag]

actually it is better to multiply by 258 since both the multiplicands range from 0 to 255, and 256*65535/(255*255) ~= 258. This is like multiplying both numbers by 257. (257*257)/256 ~= 258.

[AGS]

The alpha value does not range from 0 to 255. 255 is handled separately as "copy". Thus it ranges up tp 254. I don't know, if this makes a difference?

[Mrs Beanbag]

Originally Posted by AGS

The alpha value does not range from 0 to 255. 255 is handled separately as "copy". Thus it ranges up tp 254. I don't know, if this makes a difference?

no it won't make a difference, the "range" of alpha is still 0..255 but 255 is handled as a special case. The rest of the range 0..254 still needs to be correct for a range of 0..255.

Also of course alpha=0 is a special case as well.

[AGS]

Why can't I again see a difference between multiplying with 257 and 258?

[Mrs Beanbag]

Originally Posted by AGS

Why can't I again see a difference between multiplying with 257 and 258?

because the difference is very small! when the maximum difference is 1 part in 255 you would need to look very carefully on a really good monitor, and most of the pixels are probably exactly the same between versions.