Righto. The approach I've always used is to load the entire font (basically '!'-'~') and just use the characters from that. There's hardly ever a situation where I need weird UNICODE shit or anything else like that; something that required UNICODE would warrent a complete rewrite of the font system (and, quite possibly, much of the codebase ATM).
Anyway. I was hopeing for a 1HKO with this, but of course that wasn't going to happen -
When I saw that I lol'ed. Whatever.
Apparently creating a SDL_Surface with 1 bit per-pixel causes a lot of problems (I thought the 'depth' field was bytes per-pixel!!) There were other bugs to work out of course, but I eventually got it to a workable state. Here's the texture manager dump, so you can see the whole surface loaded into VRAM -
Now, maybe its just the font I used (Arial), but I think that looks like shit. I guess we'll have to see what it looks like when used to draw actual text and stuff. Rah!
There are some problems with this - foremost - its currently allocating a 128x128 block of texture to draw text to. When it runs out, it just gives up and stops loading the texture; what's loaded is usable, what's not is not. This is a problem - the maximum texture size I can get with a 128 block is Arial, 14pt.
My solution to this is, of course, dynamic allocation of texture memory. Basically, when the font generation code (which is over 150 lines omfg!) hits the point where its exhausted the space in the current texture block, it should write the changes to it, then request another one, and use that up.
Since each glyph is stored as a "Texture" object (basically a set of coordinates into the atlas), having disjunct texture blocks isn't a problem. In fact, its actually a better solution, because smaller textures are easier to allocate into the quadtree than larger textures. Generally. I guess since (presumably) you'd be loading your fonts at start-time it'd pan out all the same, but still.
The drawback is that the font has to keep track of multiple texture blocks to free if ever the font should be freed. Now, I'm not sure how much of a problem this is. It involves changing a Texture& to a std::vector
So yeah. Font loading now basically works. Now lets see if I can get some fancy-pants rendering going :]