Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


Okay, so I've been working on the damned font support. I hate fonts. I hope you all feel the same way, because cunting fonts are UGH!!! OMFG DIE DIE DIE!!1`

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& in like 2-3 places, but other than that, meh. I guess I'll add that to the to-do list.

So yeah. Font loading now basically works. Now lets see if I can get some fancy-pants rendering going :]
Sign in to follow this  


Recommended Comments

Don't worry, our hatred of fonts is mutual. [smile]

And everytime I see a screenshot from your logger console, I get violent flashbacks of seeing my own (and the nasty bugs that trailed in its wake).

Share this comment

Link to comment
Wait wait wait - the logging system had problems? Or did it just tell you when other code had a problem? :X

But yeah, it should remind you. I modelled it after yours, after all :D

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!