Simple font rendering library

[BenLunt]

bzt,

I thought I would experiment with your SSFN 2.0 renderer.

Currently, I have two questions/comments which I will get to in a moment.

First, thank you for the efforts. I was shy of the first version, simply because if I decided to use it, the lack of fonts was concerning and I didn't wish to try to build FreeType2 just to get a converter to convert other fonts. So thank you for the (Windows) binary in version 2.0. I haven't tried the binary yet, but I am glad it is there and look forward to using it.

First concern, and I believe a similar concern has been brought up a few times here on this forum. In your documentation, you state:

You can render to a cropped area on the framebuffer using the dst ssfn_buf_t struct. Set dst.x and dst.y to zero, and dst.ptr to "base address + offsy * pitch + offsx * 4". Then the rendered text will be limited to (offsx, offsy) - (offsx + w, offsy + h), and no pixels will be modified outside of this area.

This is misleading or confusing to me, simply because a rendered text's base line is at offsy. If the above statement was correct, wouldn't the whole first line of text be outside of this area? If I understand and have used your code correctly, it in fact does only render any pixel on and below the baseline of the rendered text because all of the rest of the text is outside (above) that line. i.e.: All but the bottom most pixel and any tails like on 'g', etc. of the rendered text is at a pixel position less than (above) offsy and your current code doesn't render it to the "screen" with the following line (line 1246):

Code: Select all

                if(dst->y + y - oy < 0) continue;

Second, and this isn't really a complaint or anything, just a word of information for documentation sake.

I use 24-bit true-color pixels on my GUI bitmaps which include windows, buttons, images, etc. Therefore, an object's bitmap uses a pixel of XXRRGGBB. The GUI uses the high byte (XX) as the transparent value, a value of 0x00 means no transparency, with a rising value giving a "percentage" of transparency with 0xFF being fully transparent.

With SSFN (via my GUI), as is, all pixels are displayed as very close representations of the pixel that was there before the rendering due to a value of 0x00 in the upper byte of the pixel. At first it seemed that nothing was being rendered, though it actually was, you just couldn't see the difference in color since they were only a few shades different.

For others that might be using 24-bit true-color pixels, you might want to know that with two very small modifications to your code, I was able to get it to render as expected.

Line 1242, I added the '~' to the fA value.

Code: Select all

 - fR = (dst->fg >> 16) & 0xFF; fG = (dst->fg >> 8) & 0xFF; fB = (dst->fg >> 0) & 0xFF; fA = (dst->fg >> 24) & 0xFF;
 + fR = (dst->fg >> 16) & 0xFF; fG = (dst->fg >> 8) & 0xFF; fB = (dst->fg >> 0) & 0xFF; fA = ~(dst->fg >> 24) & 0xFF;

Then at line 1294, I replace the high byte of the result (*Ol) with the Transparent value from the original color desired, to be consistent with my GUI engine.

Code: Select all

*Ol = ((sA > 255 ? 255 : (sA > bA ? sA : bA)) << 24) |
                            ((sR > 255 ? 255 : sR) << (16 - cs)) | ((sG > 255 ? 255 : sG) << 8) | ((sB > 255 ? 255 : sB) << cs);

(Remember to adjust for underline and strikethrough via the #define PUTPIXEL as well)

This may or may not be correct for your SSFN, but for my 24-bit true-color system, it works just fine.

Thank you for your efforts, I have enjoyed experimenting with your code and will continue to do so.

Ben
- https://www.fysnet.net/osdesign_book_series.htm