You can get some help directly from the tool by typing:
orxfontgen -h
And to get more details on one of the available parameters:
orxfontgen -h <param>
The most important ones are:
-f <FontFile>: the ttf file your want to use
-o <OutputName>: The name of the bitmap font generated, including both the texture and the config file
-t <TextFile1> [TextFile2] ...: a list of files containing all the characters you want to use in your font (most of the time people only use one that contains all the letters/numbers and other characters they want to use in-game)
-s <Size>: Height of the characters in the bitmap font, in pixels
If you want to output a monospaced font (ie. all the characters will have the same width, you can use -m).
I think it works. Which software did you use to open the file ?
I think you just have to check the alpha channel (characters are generated in this channel). In Photoshop, the alpha channel is hidden when you open a .tga file.
That sounds horrible for fonts that are not in English, like Chinese, which has thousands of characters. What I see in this post is the tool convert the font to images. Am I right? Since you have a tool to convert the font, why not make it dynamic? I didn't found it in doc, so sorry if it is already there.
Well the idea is that you feed the tool with the actual text content you're going to use in-game.
Usually those are stored in config files if you want to support localization, but any UTF-8 encoded file will work.
These would be the same files you'd use it dynamically in your game, you can even feed it source code if you hardcode your text within your code (which isn't encouraged, of course).
I don't see many advantages of doing it dynamically, mostly disadvantages:
- the FreeType2 library would need to be compiled and loaded for all supported platforms and will bloat code
- a new plugin would need to be created to support this feature as orx's core is independent from any external library
- creating the glyphs at runtime will be extremely inefficient, both in term of speed and memory (you'll still need to generate font sheets to make this impact as less as possible the runtime code, which would then be the same as generating them offline)
The only possible advantage I'd see would be to support user-typed content (or any other external content) to which you wouldn't have access when creating your game. But in this case, I'd suggest running FreeType2 yourself and create the font on the fly programmatically.
It can be done all in code (it's actually how the default internal font is created in orxFont.c) but you'll then be responsible of its deallocation as well.
Do you see any other advantages of the dynamic approach?
Wow what a quick reply!
Ok. Since it is really slow, your point makes sense to me. And external library is also an issue. The only advantage is this make TTF support a scale-able approach.
Think about visual novels, which typically have tens or hundreds kilo words. Let's assume several hundred or over 1k different chars are used, the image could be large. Anyway, a better way may be not using TTF
I understand about the scalable approach. If you really need different scales, ie. when scaling up/down from one size gives visual artifacts on screen, you can generate the font for different sizes. The font will be loaded in video memory only when used (unless you force them to stay in memory, but that's another story), so they'll mostly take place only on disk.
As for displaying a full novel, you're right about the annoying limitation. Worse case scenario you can generate a font for every 10 pages or so to display, even if there are overlaps.
But even 1K characters won't be that big of a texture by today's standards if you don't ask for huge glyphs.
For example, for a 16 pixels wide characters, a 60*16 character font (ie. 960 glyphs) will end up being roughly a 60*16*16*16*4 bytes = 983 040 bytes. Which is a 1024*256 texture.
Well, the file size looks reasonable. Sorry I didn't really do calculation. I think nice looking Chinese characters need more than 16x16 but it won't be too much more. Thanks for the replies!
No worries. Even with a 32x32 size (which is probably more than enough for nice looking Chinese characters), it'd be under 4MB.
And we could probably cut the textures by group of pages, as mentioned above.
Also please note that textures can be created programmatically, so if storage is an issue, one could still use FreeType2 to generate the glyphs/textures during loading, for example.
Comments
The most important ones are:
-f <FontFile>: the ttf file your want to use
-o <OutputName>: The name of the bitmap font generated, including both the texture and the config file
-t <TextFile1> [TextFile2] ...: a list of files containing all the characters you want to use in your font (most of the time people only use one that contains all the letters/numbers and other characters they want to use in-game)
-s <Size>: Height of the characters in the bitmap font, in pixels
If you want to output a monospaced font (ie. all the characters will have the same width, you can use -m).
Two more questions
orxfontgen -f font.ttf -t characters.txt
orxfontgen -f font2.ttf -t numbers.txt
1) What am I supposed to write into the file "characters.txt" if I want all the characters?
2) And what am I supposed to write to the file "numbers.txt" if I want only numbers.
thanks!
Well, all the characters you're going to use. Like:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ .,;!?
0123456789
I tried with a lot of fonts..
Characters = abcdefghijklmnñopqrstuvwxyzABCDEFGHIJKLMNÑOPQRSTUVWXYZ0123456789
orxfontgen -f font.ttf -t characters.txt -s 14
I think it works. Which software did you use to open the file ?
I think you just have to check the alpha channel (characters are generated in this channel). In Photoshop, the alpha channel is hidden when you open a .tga file.
Hope this help !
Well the idea is that you feed the tool with the actual text content you're going to use in-game.
Usually those are stored in config files if you want to support localization, but any UTF-8 encoded file will work.
These would be the same files you'd use it dynamically in your game, you can even feed it source code if you hardcode your text within your code (which isn't encouraged, of course).
I don't see many advantages of doing it dynamically, mostly disadvantages:
- the FreeType2 library would need to be compiled and loaded for all supported platforms and will bloat code
- a new plugin would need to be created to support this feature as orx's core is independent from any external library
- creating the glyphs at runtime will be extremely inefficient, both in term of speed and memory (you'll still need to generate font sheets to make this impact as less as possible the runtime code, which would then be the same as generating them offline)
The only possible advantage I'd see would be to support user-typed content (or any other external content) to which you wouldn't have access when creating your game. But in this case, I'd suggest running FreeType2 yourself and create the font on the fly programmatically.
It can be done all in code (it's actually how the default internal font is created in orxFont.c) but you'll then be responsible of its deallocation as well.
Do you see any other advantages of the dynamic approach?
Hope this helps!
Ok. Since it is really slow, your point makes sense to me. And external library is also an issue. The only advantage is this make TTF support a scale-able approach.
Think about visual novels, which typically have tens or hundreds kilo words. Let's assume several hundred or over 1k different chars are used, the image could be large. Anyway, a better way may be not using TTF
As for displaying a full novel, you're right about the annoying limitation. Worse case scenario you can generate a font for every 10 pages or so to display, even if there are overlaps.
But even 1K characters won't be that big of a texture by today's standards if you don't ask for huge glyphs.
For example, for a 16 pixels wide characters, a 60*16 character font (ie. 960 glyphs) will end up being roughly a 60*16*16*16*4 bytes = 983 040 bytes. Which is a 1024*256 texture.
And we could probably cut the textures by group of pages, as mentioned above.
Also please note that textures can be created programmatically, so if storage is an issue, one could still use FreeType2 to generate the glyphs/textures during loading, for example.