The Place to Start for Operating System Developers
http://f.osdev.org/
Code: Select all
*(uint32_t*)physbuff = color;Code: Select all
physbuff[0] = clamp(color.r + physbuff[0] * (color.a / 255.0f), 0, 255);
physbuff[1] = clamp(color.g + physbuff[1] * (color.a / 255.0f), 0, 255);
physbuff[2] = clamp(color.b + physbuff[2] * (color.a / 255.0f), 0, 255);
physbuff[3] = clamp(physbuff[3] + color.a, 0, 255);
Why are you doing additive blending instead of alpha blending?Ch4ozz wrote:New transparency code:
Either implement each step separately, then, or learn about matrices. In most cases, matrices are just a practical and meaningful way of representing data and performing operations on it, but you can implement the same algorithm with each value separately (different types of matrix multiplication can get a little messy if you're working with the values separately, though). Just think of matrices like arrays, and matrix operations as operations on arrays (it might help to implement each of the main matrix operations as functions, and call then as necessary to implement an algorithm that works with matrices, rather than worrying about the details of how those operations work and how the data is transformed to the required end result).DeezRamChips wrote:I don't know anything about matrices
Haven't learned that already
Code: Select all
; alpha_blend_colors:
; Blends two colors
; In\ EAX = Foreground
; In\ EBX = Background
; In\ DL = Number of bits to shift foreground color (1 = less transparent, 4 = most transparent, 0 = no change)
; Out\ EAX = New color
align 16
alpha_blend_colors:
or dl, dl
jz .no_change
cmp dl, 4
jg .no_change
push rcx ; my tests have shown that PUSH RCX is a few cycles faster than PUSH CX --
; -- so this probably gives more performance on slow CPUs and maybe Bochs
; I thought PUSH CX would be faster because it's less data, but oh well..
and eax, 0xF0F0F0
and ebx, 0xF0F0F0
mov cl, dl
shr eax, cl
shr ebx, 1
and eax, 0x7F7F7F
and ebx, 0x7F7F7F
lea eax, [eax+ebx] ; probably faster than add eax, ebx
pop rcx
ret
.no_change:
retCode: Select all
resultBlue = (blue1 * alpha + blue2 * (alphaMax - alpha) ) / alphaMax;
resultGreen = (green1 * alpha + green2 * (alphaMax - alpha) ) / alphaMax;
resultRed = (red1 * alpha + red2 * (alphaMax - alpha) ) / alphaMax;Code: Select all
resultBlue = pow( (pow(blue1, 1/2.2) * alpha + pow(blue2, 1/2.2) * (alphaMax - alpha)) / alphaMax, 2.2);Code: Select all
resultBlue = (blue1 * alpha + blue2 * ~alphaMax) >> 8;
I love that you always know some hardcore stuff that seemingly few other people knowBrendan wrote:This causes images to be a fraction darker than they should be (because it's dividing by 256 and not dividing by 255, and because of "round towards zero division"); and lack of gamma correction magnifies this error (especially for darker colours); but it's faster than doing "pow()" twice per pixel.
Just registered to say this:Brendan wrote:Note that (for 8-bit alpha), most people do it wrong, like:This causes images to be a fraction darker than they should be (because it's dividing by 256 and not dividing by 255, and because of "round towards zero division"); and lack of gamma correction magnifies this error (especially for darker colours); but it's faster than doing "pow()" twice per pixel.Code: Select all
resultBlue = (blue1 * alpha + blue2 * ~alphaMax) >> 8;
Code: Select all
dest_a = ~src_a;
result_r = (src_r * src_a + dest_r * dest_a + 0xFF) >> 8;
result_g = (src_g * src_a + dest_g * dest_a + 0xFF) >> 8;
result_b = (src_b * src_a + dest_b * dest_a + 0xFF) >> 8;