OSDev.org

Hello,

I've left text mode and am on to using graphics mode...My first question is how to store, say, an 8x8 bitmap font. I read the drawing in protected mode section of the wiki, and as far as the font thing goes it tells you what the encoding of the letter 'A' is, not how to store the encoding.

Say I have an uppercase C: How would I store that in such a way that I can print it (in 320x200x16)?

The most compact way would be to store each row as a byte containing the bitmap for that row. For example, that 'C' character bitmap would become 0x18, 0x3C, 0x66, 0x60, etc. (where the most significant bit is on the left.)

And to print the character I would find the most significant bit and lowest significant bit and print the pixels with those? Let me get this right:

I believe that the MSB of say 0x65 would be 0x06 and the LBS 0x05, correct, right?

And searching on google I find multiple ways to find the MSB, none of which seem to work.


Am I right, or way off?

no not the MSB or LSB i'm looking for the upper and lower 4 bits. I already know how to do that. Thanks, Matt

MSB of byte 0x65 (0110 0101) is zero.

For example, 0x65 would decode into:
(blank)(dot)(dot)(blank)(blank)(dot)(blank)(dot)

casnix wrote:And to print the character I would find the most significant bit and lowest significant bit and print the pixels with those?

To print a character, all you need to do is decode the pixels. Test every bit in a row, if you find a '1' this means you need to plot the pixel at current position(graph) and if you find a '0', you need to ignore this pixel and move a step forward to next position(graph). You need to continue like this until you decode every row of this character.

casnix wrote:Say I have an uppercase C:

Code: Select all

...XX...
..XXXX..
.XX..XX.
.XX.....
.XX.....
..XXXX..
...XX...

How would I store that in such a way that I can print it (in 320x200x16)?

To store this font you'd have store each pixel bit by bit and each row byte by byte. Meaning that your font should be stored like this: In this case, each row is stored in a byte, meaning that 0x18 stores pixels of the first row and 0x00 stores pixels of the last row.
And of course, you wouldn't want to store individual characters like I did(unsigned char C[8]) and probably want to store every characters in a font table. This is a piece of a cake, once you understand the encoding and decoding process.

And oh yes, this way of storing fonts is traditional and comes with limitations. You may want to adopt a new way of storing fonts, once you're done with this. I've my own implementation, if any one is interested.............

Best Regards,
Chandra

Chandra wrote:You may want to adopt a new way of storing fonts, once you're done with this. I've my own implementation, if any one is interested.............

Although I have not yet started my implementation on GUI, my plan is to support TTF files, and use FreeType to load them into textures, or write a subset of FreeType.

So I'm interested in why you choose to have your own implementation, and the benefits over bitmap and TTF. By knowing these I may refine my own design

bluemoon wrote:So I'm interested in why you choose to have your own implementation, and the benefits over bitmap and TTF. By knowing these I may refine my own design

Basically, things start to get complex when you step into the GUI world. The first thing, the traditional bitmap font can't cover is the character spacing. To gain a better appearance, characters have to arranged in such a way that, the space between the characters can be adjusted according to the combination of letters. For instance, the spacing between the characters 'l' & 'l' in the word "hill" must be less than the spacing between the characters 'a' & 'l' in the world "hal". Typical spacing for 'l' & 'l' in the word "hill" is 1 wheras, that for 'a' & 'l' in the word "hal" is 2. Another significant improvement over the fonts can be made by including the header, which defines how may characters are defined in the font table, what colors are being used, global dimensions etc. This will allow the font decoder to draw a smooth font(anti-aliased) and adds to the better resizing of the font. In the contrary, the process of decoding a font is slow which might not be a good price to pay when performance matters.

Cheers.