VGA Fonts: Difference between revisions

 

But how do you know what to draw? It's stored in data matrix called bitmap fonts.

</pre>

The full bitmap contains bitmaps for every character, thus it's 256*16 bytes, 4096 bytes long. If you want to get the bitmap for a specific character, you have to multiply the ASCII code by 16 (number of rows in a character), add the offset of your bitmap and you're ready to go.

 

== How to get fonts? ==

Easiest way, but increases your code by 4k. There are several sources that provide the entire font in binary or source format so you do not need to manually write it out.

=== Store it in a file ===

=== Get the copy stored in the VGA BIOS ===

It's a standard BIOS call (no need to check it's persistence). If you're still in real mode, it's quite easy to use.

;in: es:di=4k buffer

;out: buffer filled with font

rep movsd

pop ds

 

=== Get from VGA RAM directly ===

Maybe you're already in protected mode, so cannot access BIOS functions. In this case you can still get the bitmap by programming VGA registers. Be careful that the VGA always reserves space for 8x32 fonts so you will need to trim off the bottom 16 bytes of each character during the copy:

;in: edi=4k buffer

;out: buffer filled with font

out dx, ax

;clear even/odd mode (the other way, don't ask why)

out dx, ax

;copy charmap

mov ax, 0302h

out dx, ax

out dx, ax

mov dx, 03ceh

mov ax, 1005h

out dx, ax

out dx, ax

It worth mentioning that it has to be done '''before''' you switch to VBE graphics mode, because VGA registers are usually not accessible afterwards. This means you won't be able to map the VGA card's font memory to screen memory, and you will read only garbage.

 

And finally we came to the point where we can display a character. I'll assume you have a putpixel procedure ready.

We have to draw 8x16 pixels, one for every bit in the bitmap.

//this is the bitmap font you've loaded

unsigned char *font;

int cx,cy;

int mask[8]={1,2,4,8,16,32,64,128};

 

for(cy=0;cy<16;cy++){

}

}

The arguments are straightforward. You may wonder why to subtract 12 from y. It's for the baseline: you specify y coordinate as the bottom of the character, not counting the "piggy tail" in a glyph that goes down (like in "p","g","q" etc.). I other words it's the most bottom row of letter "A" that has a bit set.

 

Although it's mostly useful to erase the screen under the glyph, in some cases it could be bad (eg.: writing on a shiny gradiented button). So here's a slightly modificated version, that uses a transparent background.

//this is the bitmap font you've loaded

unsigned char *font;

int cx,cy;

int mask[8]={1,2,4,8,16,32,64,128};

 

for(cy=0;cy<16;cy++){

}

}

As you can see, we have only foreground color this time, and the putpixel call has a condition: only invoked if the according bit in the bitmap is set.

 

Of course the code above will be excruciatingly slow (mostly due to doing one pixel at a time, and repeatedly recalculating the address for each pixel within the "putpixel()" function). For much better performance, the code above can be optimised to use boolean operations and a "mask lookup table" instead. For example (for an 8-bpp mode):

 

//this is the bitmap font you've loaded

unsigned char *font;

}

}

 

In this case the address in display memory is only calculated once (rather than up to 128 times) and 8 pixels are done in parallel (which removes the inner loop completely).

The main downside for this approach is that you need a different function for each "bits per pixel", except that 15-bpp and 16-bpp can use the same code. For worst case (32-bpp) the lookup table costs 8 KiB. The lookup table for 32-bpp can be re-used for 24-bpp, and for 4-bpp no lookup table is needed at all. To support all standard bit depths that VBE is capable of; this gives a total of 5 versions of each "draw character" function (4-bpp, 8-bpp, 15-bpp and 16-bpp, 24-bpp, 32-bpp) and 3 lookup tables (8-bpp, 15-bpp and 16-bpp, 24-bpp and 32-bpp) which cost a combined total of 14 KiB of data if you use static tables (rather than dynamically generating the desired lookup table if/when needed).