Jump to content

  • Log In with Google      Sign In   
  • Create Account


Non-fixed width fonts in games


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 MatejaS   Members   -  Reputation: 134

Like
0Likes
Like

Posted 01 July 2014 - 11:56 AM

Hello everyone,

I am making a game in C++ and I want to add text.I have a bitmap font which is not fixed-width (all the characters don't have equal width).

Assume I have a function Texture::Draw(rect,x,y) which draws the region rect of the texture at (x,y).

I want to know what's the best way to store data for the font. I've got a few ideas:

1. To make an array of Rect-s (where Rect is my class that implements a rectangle).

2. To make a text file which stores the data about each character.

 

I would like to know which one is better,and is there a better on,and also how do ttf fonts store data about their characters?

 

Thanks,

MatejaS



Sponsor:

#2 fastcall22   Crossbones+   -  Reputation: 4222

Like
4Likes
Like

Posted 01 July 2014 - 12:17 PM

Usually when doing font rendering in games, a select number of glyphs are packed into an image. This image also has metadata, either stored alongside the image or in a separate file, which stores information about where in the image a glyph is, how large the glyph is, what kind of kerning adjustments are needed with which pair of glyphs, and etc. Take a look at bmfont and how it generates its font files. (Sample here: Quick tutorial variable width bitmap fonts.)

Once you have the image and the metadata, it is only a matter of storing this data into a data structure. An associative array or tree is usually the best approach, especially when you take into concern characters outside of the ASCII range.


On the topic of TTF, these files can be thought of executable scripts which transforms a state into a series of outlines.

Edited by fastcall22, 01 July 2014 - 12:18 PM.

c3RhdGljIGNoYXIgeW91cl9tb21bMVVMTCA8PCA2NF07CnNwcmludGYoeW91cl9tb20sICJpcyBmYXQiKTs=

#3 Sik_the_hedgehog   Crossbones+   -  Reputation: 1596

Like
1Likes
Like

Posted 01 July 2014 - 08:49 PM

On the other hand, if you need only some trivial font rendering (i.e. no composite characters, no ligatures, no bidirectional rendering, etc.), really all you need is the graphic of the glyph and its width (and then you just advance the width for each character). Still may be a good idea to store that data in a file, to make it easier to modify the font.

 

Whether that's enough for you or not depends on which languages you're planning to support. For many languages (e.g. Western scripts and CJK), you can get away with that. If you want to support other languages, you're better off getting a TrueType renderer.


Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

#4 Krohm   Crossbones+   -  Reputation: 3044

Like
0Likes
Like

Posted 03 July 2014 - 12:45 AM

Because of various reasons I had to spend quite some effort on my font systems. While rasterization quality is still low, positioning is fairly accurate.

My suggestion is to look at OS facilities for advance width of each glyph. For windows that's Uniscribe. For *nix is either Pango or Harfbuzz... I think.



#5 NightCreature83   Crossbones+   -  Reputation: 2734

Like
0Likes
Like

Posted 03 July 2014 - 10:02 AM

On the other hand, if you need only some trivial font rendering (i.e. no composite characters, no ligatures, no bidirectional rendering, etc.), really all you need is the graphic of the glyph and its width (and then you just advance the width for each character). Still may be a good idea to store that data in a file, to make it easier to modify the font.

 

Whether that's enough for you or not depends on which languages you're planning to support. For many languages (e.g. Western scripts and CJK), you can get away with that. If you want to support other languages, you're better off getting a TrueType renderer.

 

You need a bit more you at least need its base line offset because other wise you get text that goes up and down and looks really ugly. No game I have worked on is actually using a proper font renderer its all bitmap fonts, with SDF rendering so that one bitmap page can generate all font sizes.

 

For languages other then EFIGS you generally use different bitmap page and dont load the EFIGS pages. And you only load Kanji alphabet for Japanese for example. Even in the EFIGS languages you dont actually include all the accented characters if you can get away with it.

 

Generally you need baseline, advance and kerning information about a font to be off passable quality whilst rendering text, not having kerning or baseline information makes your text look really weird if you aren't dealing with a fixed width font.
 


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS