OSDev.org

Hey guys, I was curious.. Has anyone accomplished Anti Aliasing in their Os?

Thanks, Matt

In general, its a compiler and CPU problem than an OS problem?

The Mill CPU is immune to false aliasing. Its a statically scheduled machine so loads are scheduled to return results in some future cycle.

The station doing the load spies on the addresses of all intervening stores, and reloads any that are overwritten.

Immunity!

@willedwards: ... how is this related?

@PearOs: I would presume anyone who has implemented a semi-advanced GUI would have some form of anti-aliasing on fonts (first name that springs to mine is Klange's TorauOS, but I would expect Pedigree to also have AA)

Aliasing can refer to a graphics thing, or a pointer thing.

Hi,

PearOs wrote:Hey guys, I was curious.. Has anyone accomplished Anti Aliasing in their Os?

I've done some basic anti-aliased graphics (lines, font data, etc).

I also wrote a 3D render that splits shapes into horizontal "line segments" with floating point start and end to get perfect horizontal anti-aliasing for everything; then added a form of super-sampling to it to get some anti-aliasing in the vertical direction (e.g. generate "n * screen_lines" of pixel data with perfect horizontal anti-aliasing, so that each screen line is the average of "n lines").

After that I spent ages researching a "triangle rendering pipeline". This makes it extremely easy to get perfect anti-aliasing in all directions (once you've pounded all the graphics into a suitable "non-overlapping triangles" format). The hard part is converting all the graphics into that "non-overlapping triangles" format to begin with.

Is there a specific type of anti-aliasing you're thinking about?


Cheers,

Brendan

Brendan wrote:Hi,

PearOs wrote:Hey guys, I was curious.. Has anyone accomplished Anti Aliasing in their Os?

I've done some basic anti-aliased graphics (lines, font data, etc).

I also wrote a 3D render that splits shapes into horizontal "line segments" with floating point start and end to get perfect horizontal anti-aliasing for everything; then added a form of super-sampling to it to get some anti-aliasing in the vertical direction (e.g. generate "n * screen_lines" of pixel data with perfect horizontal anti-aliasing, so that each screen line is the average of "n lines").

After that I spent ages researching a "triangle rendering pipeline". This makes it extremely easy to get perfect anti-aliasing in all directions (once you've pounded all the graphics into a suitable "non-overlapping triangles" format). The hard part is converting all the graphics into that "non-overlapping triangles" format to begin with.

Is there a specific type of anti-aliasing you're thinking about?


Cheers,

Brendan

Thanks for the reply Brendan, I was thinking of a grid based implementation because it seems to be fast if done right. I am using this for fonts as I dislike the rough edges on the characters. I started to write an implementation of grid based anti aliasing in C# for my Os, and it worked but its slow for a 6080x64 bitmap font file, so I am going to rewrite it in Assembly by hand to optimize it a bunch. I almost wish I had SDL ported to my Os, but oh well.

- Matt

thepowersgang wrote:@willedwards: ... how is this related?

@PearOs: I would presume anyone who has implemented a semi-advanced GUI would have some form of anti-aliasing on fonts (first name that springs to mine is Klange's TorauOS, but I would expect Pedigree to also have AA)

Thanks thepowersgang, I will have to look and see how they managed it. One thing I need to figure out is if I implement True Type Fonts, I will have to solve the issue of forming a bitmap for each character every time the font renders. Bitmap based fonts are neat in the fact they don't require much work and can be rendered extremely fast in my Os. I just hate how I can't have multiple font sizes unless I either resize the whole bitmap.

Thanks, Matt

Hi,

PearOs wrote:Thanks for the reply Brendan, I was thinking of a grid based implementation because it seems to be fast if done right. I am using this for fonts as I dislike the rough edges on the characters. I started to write an implementation of grid based anti aliasing in C# for my Os, and it worked but its slow for a 6080x64 bitmap font file, so I am going to rewrite it in Assembly by hand to optimize it a bunch. I almost wish I had SDL ported to my Os, but oh well.

For fonts and grids; I'd pre-convert the font data into "8 bits of alpha per pixel" format. Then it's something like "red = old_red * (alpha_from_font_data/255) + character_red * (1 - alpha_from_font_data/255)", with the same for green and blue, for each pixel; where you'd use lookup tables (or maybe SSE/AVX) for the calculations - e.g. "red = lookupTable[old_red][alpha] + lookupTable[character_red][reverse_alpha]".

Note: There are problems involving gamma. For perfect results (with less overhead), your pixel data would be kept in "no gamma" format (e.g. with floating point red, green and blue or something) and then converted into sRGB afterwards.


Cheers,

Brendan

The libfreetype is open source, support all font file format, and can load fonts as 8bit grayscale-alpha bitmaps, it also supports LCD. Then you just have to multiply this alpha-grayscale by the color of the font, and use the gray scale value as the alpha value and then do a regular alpha blending blitting.

If you want to have multiple size from bitmap, you can use a bilinear filtered resizing of each character slot when you do draw it. It will not manage very well if you need to change the size too much from the original size. Otherwise you have to have one bitmap per font size.

If you want to do the anti aliasing in real time starting from the vectorial form, it can manage resize better , the basic AA is mostly about averaging all pixel around any pixel you draw.

The simplest way, h0bby1 has mentioned it, would be freetype2. It is easy to port (it only requires a standard libc like newlib) and is relatively easy to handle and fast to include into your system. The only thing I could recommend over the basic dependency is shared memory (to put the font there, toaru is doing it this way)

Beside that, you will have to implement alpha blending by yourself. You just have to calculate the color value of the two overlapping colors. We had a thread on that not long ago: Thread.

It seems to me that klange really needs to come here and lead the discussion. 2 references to ToaruOS already.

I have ported Freetype 2 to my operation system, and from there it was pretty easy. Freetype2 offers a very good API and I incorporated that into my Window Manager.
If you have any questions about it, feel free to ask