Let's start with the last problem of drawing an anti-aliased line on a general background. if Cb = (Rb, Gb, Bb) is the color of the background, Cl = (Rl, Gl, Bl) is the color of the line and A is the alpha value of the current pixel, then the final color will be A*Cl + (1 - A)*Cb. If the background is not opaque, the formula is a little more complicated. This formula assumes the colors are expressed in linear RGB (you thus have to convert from/to sRGB/other gamma corrected color spaces if your colors are expressed using this color space)..

I personally think it is easier to center the integer coordinates to the center of the pixels when drawing lines with integer coordinates. If you thus have a vertex of the line at (0,0), the pixel at (0,0) should be completely filled.

Let's start with the last problem of drawing an anti-aliased line on a general background. if Cb = (Rb, Gb, Bb) is the color of the background, Cl = (Rl, Gl, Bl) is the color of the line and A is the alpha value of the current pixel, then the final color will be A*Cl + (1 - A)*Cb. If the background is not opaque, the formula is a little more complicated. This formula assumes the colors are expressed in linear RGB (you thus have to convert from/to sRGB/other gamma corrected color spaces if your colors are expressed using this color space)..

So if you drawing wu-line and this algorithm is based od

spliting 100% color on two pixels based on the fraction part

of coordinate - it is the alpha that youre splitting? (I thought

it was collor but i was probably wrong) - how would

it like look like if you draw 255 white on 128 gray? say alpha is

50% - 50% so this is two pixels of 192 - if alpga is 80% 20%

this would be 80%*255+20%*128 up pixel and 20%25+80%*128

down

does it make opticaly right line?

as to linear rgb - my monitor is not linear i thing (On my old crt monitor a I even was doing hand made test by comparing

chess-like grids of white and black to corresponding gray

color - and it showed that those given in docs formula

with gamma is quite correct with my experiments outcome

Probably this lcd monitor i use now is like that too, so this

is non linear so when drawing wu-line on some bitmap

picture (wallpaper or something) what should i do - is

the wallpaper in linear values probably no and this is already gamma corrected so i should ungamma it blend my line linear

and then gamma the result,

no?

In general your entire pipeline should be linear. Gamma correction should be done only when importing things and drawing to the screen. In your case you probably need to convert to/from linear RGB before and after the computations.

What I call alpha or opacity or coverage is the fraction of the pixel covered by the line (assuming in your case that the line is 1px wide. If you have 255 white and 128 gray with an alpha of 50% you get the following:

0.5*(255, 255, 255) + 0.5*(128, 128, 128) = (191, 191, 191) (the result has been rounded)

When using the formula with percentages of 0%, 10%, .. 100% I get the following (rounded) values of gray: 128, 141, 153, 166, 179, 191, 204, 217, 230, 242, 255.

In general your entire pipeline should be linear. Gamma correction should be done only when importing things and drawing to the screen. In your case you probably need to convert to/from linear RGB before and after the computations.

What I call alpha or opacity or coverage is the fraction of the pixel covered by the line (assuming in your case that the line is 1px wide. If you have 255 white and 128 gray with an alpha of 50% you get the following:

0.5*(255, 255, 255) + 0.5*(128, 128, 128) = (191, 191, 191) (the result has been rounded)

When using the formula with percentages of 0%, 10%, .. 100% I get the following (rounded) values of gray: 128, 141, 153, 166, 179, 191, 204, 217, 230, 242, 255.

ok, i understand, tnx

though when speaking about linear and adding/blending two

sprites (loaded from bitmap for example) - is there a way you know if they are linear or already gamma distorted - i think al images are probably gamma distorted (so almost ebery case i should degamma them - but im not sure

as to keeping linear - this is just a problem that i was mentioned,

i could hold a linear nitmap buffer of my frame then before blitting just gamma it manually in some heavy cpu pass - but i think it will slow down it all quite heavy

it better be some option to blit some linear buffer making some hardware acclerated gamma in the blit time but as far as i know i had no such option in winapi

You can preprocess all your sprites in a build step so you do not have to do it at run-time. You should ship your game with all the images in a linear color space and only gamma correct the final frame in a final postprocessing step.

You can preprocess all your sprites in a build step so you do not have to do it at run-time. You should ship your game with all the images in a linear color space and only gamma correct the final frame in a final postprocessing step.

Imo this all should be done on hardvare display level I mean no gamma should be applied on a file level or ram level - I mean all the images gifs, jpgs bitmaps should be linear only final display level should do gamma - for obvious reasons (but this is some different story, all the gamma story in files is some flaw of computer sustems of today (or at least it seems so to me))

I draw antialiased lines and polygons with a lib I make for my lang.

I clip the lines and polygons..

this is the C implementation..

https://code.google.com/p/reda4/source/browse/trunk/MV/r4wine/graf.cpp

use, improve and share.