Optimized Alpha-Blending in asm?

[AGS]

Ah! And is this new method as accurate as the divs-version?

[Mrs Beanbag]

with the multiplication by 258 it should be accurate to 2 parts in 65535 (255*255*258/256 = 65533.0078...)

that should be good enough for anyone

[AGS]

But it's more accurate and faster than the methode with the lsr #8 (instead of the div by 255), right? An lsr takes double as cycles as the amount of bits that are shiftet.

[Thorham]

Originally Posted by AGS

But it's more accurate and faster than the methode with the lsr #8 (instead of the div by 255), right? An lsr takes double as cycles as the amount of bits that are shiftet.

On 20s and 30s eight bit shifts and swaps are all four cycles when executed from the cache. For shifting more than eight bits you have to add two cycles (swap is faster when you can use it, but you can't always, because it's essentially a cheap rotate).

On the 68000 shifts take up more cycles per bit.

[Mrs Beanbag]

on 68000, lsr takes 6+2n cycles, swap takes 4 cycles, so yes it is both more accurate and faster.

on 68020+, however, lsr and swap take the same time. But then 68000 doesn't have muls.l anyway. muls.l is much slower than muls.w, too. We could instead multiply alpha by 129 and use a muls.w followed by a left shift.

[AGS]

Originally Posted by Mrs Beanbag

We could instead multiply alpha by 129 and use a muls.w followed by a left shift.

Please give me the example. Will it still work with swap then or ... ?

[Mrs Beanbag]

well it would be either lsl #1 followed by swap, or lsr #7 and lsr #8. We'd need to shift right 15 bits instead of 16.

[AGS]

Ok, I tried it this way:

	moveq	#0,d0
	moveq	#0,d2

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

		moveq	#0,d0

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

Doesn't work though.

[AGS]

Originally Posted by Mrs Beanbag

well it would be either lsl #1 followed by swap, or lsr #7 and lsr #8. We'd need to shift right 15 bits instead of 16.

Doesn't the highest bit dissapear in an lsl #1,d0?

[Mrs Beanbag]

can't see why not. it would help to have a more detailed description of the not working.

those first two moveq #0s are inside the loop, right?

Originally Posted by AGS

Doesn't the highest bit dissapear in an lsl #1,d0?

Multiplying by 258 or multiplying by 129 followed by a left shift should be the same. I hope that seems obvious. Lsl is no different to Asl, the sign is only important in right shifts.

254*129 = 32766 < 32768 so that shouldn't overflow. 255 is handled elsewhere. hmm...

[AGS]

Yes they are inside. Here's what it looks like. None of the transparent pixels are drawn.

[Mrs Beanbag]

and the correct result?

[AGS]

Here:

[JimDrew]

If you guys don't mind burning 64K of memory, this would be way faster using a simple lookup table.

[AGS]

How can I measure the speed? It's running in an OS app. Looking up the fields with the seconds and micros in the intbase did not reveal much. It's seemingly too fast for intuition updating those fields.

[alkis]

call it a gazillion times

[Mrs Beanbag]

so where is D2 being read from memory?

[AGS]

AH! It was cleared after the read! Thus all partially pixels became total transparent. I am now measuring the speed.

[AGS]

It works, but it turns out being 5 seconds slower (66 vs 71) at 3000 iterations, at least here in FS-UAE.

ps: I think this is because for the emulation there is no difference between muls.w and muls.l and then the additional lsl.l takes more time. @Toni Wilen: What do you mean?

[AGS]

@Mrs Beanbag

I compared speed with the original muls/divs version and found that the muls/divs version is faster than the new optimized variant by 3 seconds. And additionally, when we draw the same alpha picture onto the screen over and over again, the result is surprising. Left is the variant with muls and divs, and right the new optimized variant. Seems like something is going wrong?