Often, the actual rendering methods consist of the following:
There is a class/struct that contains a foreground color, a background color and a character number to describe a cell. This, to a degree, mimics what went on in video memory for the DOS text screen, where JetLag grew up. The main differences are that instead of 16 colors to pick for foreground (and a choice of blinking or not) and 8 colors for background, I have standard 24 bit color for both items, and no blinking (although, if I really wanted, I could do the blinking if I want, but JetLag causes enough siezures as it is).
There is a class/struct that contains a 2D array of 40 columns and 30 rows. These numbers are used because the intended destination is 640x480 (although it could really be 320x240 and no one would notice). The DOS text screen I used to use was 40x25, so when JetLag moved to windows, it added five rows. For this class/struct, there are typically function which mimic plotting individual character, horizontal and vertical lines of characters, filled rectangles of characters, and strings.
The screen class kept track of each character cell, and had a flag that tells whether or not it has changed. This sped along the rendering process, because I would then do dirty rectangle updates with ONLY the invalid parts.
It's not going to be as simple, this time. Smoothe scrolling, shaking the screen, having floating score adds, flying bricks, and other similar items mean I have to redraw the screen every time. Fortunately, the poly count is relatively low: 4,800 for just the 40x30 screen (two polys for background, two polys for foreground).
Another fortunate thing is that I don't have to do a two stage rendering for each character. The entire rom font bitmap gets loaded into a texture. The characters on this bitmap are white, so the only thing I have to do to color them is change the diffuse color. Before, I had a small 16x16 surface(the size of a character in the bitmap) that I would clear out the color I wanted the character to be, and then I would render from the rom font bitmap, using white as the transparent color, and then blit from the 16x16 surface onto the screen using black as the transparent color. This means I never have been able to use true black characters. I always had to settle for dark gray (#101010).
Now I'm using alpha testing to do the transparency. I can use black! Real black!
Another issue has always been that I first had to clear out the cell with the background color, and then build the character image, and finally blit the character onto the screen. With a simple z-buffer, I can render the alpha tested character in the foreground first, and then render the background behind it, and the character pixels will not be overwritten.