Nowadays, I develop a game which need custom font(ttf) to print the text in the game.
But now, orx doesn't support ttf. I think it is somewhat reasonable since ttf parsed may affect the performance of the game. The solution to replace this feature is using orxFontGen to generate a bitmap as a custom font. But the problem is the size of the letters in the bitmap is not the same. Some letters need a broad width while some need a narrow width relatively. now if every letter is the same, the space between letters will be broad, and have a bad effect to the beauty of the game.
my solution is to store every letter's width(get from ttf face's glyph advance) in the font section in config. and display every letter according to it. To realize it the places to modify include the orx lib, plugins, and the font gen tool.
I think I could complete this modification for orx by myself. But Before I work on it, I want to ask you is there any better solution to this issue. If agree with it, I will modify them. and hope to sync with thunk.
Maybe another solution to this is to realize ttf support. But it seems cost more time.
Changing orxFontGen to generate characters with different sizes isn't a big issue. Nor is adapting the internal code for storing width for each character than globally.
The big problem that prevented me from supporting non-monospaced fonts is how to describe a different width for each character in config file.
I could only think of two options, both of which have very strong limitations.
If you can think of a way to overcome that very specific problem (ie. how to describe each character width in config that would work for all cases), supporting non-monospaced fonts will be very easy.
I don't know whether I understood you correctly, but could it be something like this?
Texture = path
CharacterList = "IJK"
CharacterSize = (5,20,0)#(10,20,0)#(10,20,0)
Unfortunately this one, in addition of not being very human readable for people wanting to create bitmap fonts manually (ie. that are not based on ttf), limits the numbers of charaters to 255 (you can't have more than 255 items in a config list).
As you know very well, it's not much a limitation for short latin-like alphabets but gets more tricky for languages such as Chinese.
The other option would have been to have a collection of key-value pairs for all the defined characters (i = (5, 20, 0), ...) but that wouldn't work for special config characters such as ';', '=', ...
So the first option is dicarded.
What if you define an escape sequence for those special chars in the second option? Something like
i = (5,20,0)
; = (5,20,0)
= = (10,20,0)
To make things uniform you could require that all chars must have the escape char preceding them. Like
i = (5,20,0)
; = (5,20,0)
= = (10,20,0)
I could also go with the "none" markers used for block values and have block keys. Maybe that would be more homogeneous. That would make the parsing verification more complex though.
For now I just commited a change that allows 65535 values per list without changing the memory footprint by packing some fields for the config value structure. Accessing long lists are more costly than short lists, but in the case of fonts, we only access the list when loading a font so that shouldn't matter at all.
I'll add non-monospaced font support, including the orxFontGen tool, whenever I get some time, probably in the coming days.
I'll try to keep the font definition compatible with what is used now so that people won't need to make any change to their code/config when using monospaced fonts.
I think the second suggestion given by Peso is good but I think if do it like that, the key in the config will be too long to manage it difficultly and waste more storage.
Besides,I believe the first option is better and it is the way I want to realize. the number of Characters in a font are so many that users is difficult to manage it manually. Not many people likes to modify this long config manually. Therefore, the best way to do this feature is to use the font gen tool.
the other issue is the difference between each letter would be only the width of letter, the height could still be the same. Therefore the array we only need to record is the widths.
Moreover, the list could be still limited to 255.
you could use CharacterWidth[Int] meanwhile CharacterWidth2,CharacterWidth3,.....if the charaters is more than 255.
the example is like this:
Texture = path
CharacterList = "....." (more than 255)
CharacterSize = (32,32,0)
CharacterWidth1 = (5,20,0)#(10,20,0)#(10,20,0)#.....(255 times)
CharacterWidth2 = (x,y,0)#.....
Thanks for your help...
and best wishes to your family and your mother. And I believe they include your father will be proud of you.
As for non monospaced-fonts, orx now support them. It's 4 AM here, and I just finished writing the code so there might be some bugs in it.
I haven't updated the orxFontGen tool yet, I'll try to do it soon (but not tonight, I need some rest ^^).
Here's how it works:
If CharacterSize is defined, the font will be monospaced and nothing changes.
If it's not defined, orx will look for CharacterHeight and CharacterWidthList.
The first one is a single float value whereas the second one is a list of all the character widths. It'll only work if the list contains one width for each character defined in the CharacterList string. The lists can now go up to 65535 values so we should be fine.
Pay attention to your health. don't be so tired.
nowadays, gmail in China is crazy slow, so I post some question here.
And it's better to ask questions here anyway so that it benefits to everybody.
orxFontGen can now generate both monospace and non-monospace fonts. You can also add padding to the characters themselves, which might turn useful for non-monospace fonts when you don't want the characters to be glued together.
orxFontGen --help will provide details about the new parameters (-m / -p).
Let me know if you get any issues.
EDIT: I only commited the windows binaries, if you want to run it on linux/mac you'll need to compile it yourself and replace liborx(d).a in the /lib folder with one you compiled yourself with static debug/release targets (non-embedded).
The bad news is that orx will not support backward glyph positionning which might introduce extra spaces visually when the advance component has been artificially extended. The reason for that is that we use a triangle strip for text display and going backward will have both a memory and CPU impact.
To work around badly designed font, I'll introduce a packed mode in orxFontGen that will pack glyphs as much as possible and use the padding for extra spacing. That will be the default mode but I'll add a switch (-a) to use the exact glyph advance value instead. Should be ready shortly.
the ttf I use is Materhorn.ttf
Texture (had to convert it to PNG and negate it so that it can be viewed in the forum):
Which version did you use? The windows one from the svn or one you compiled yourself?
but mine is like this...
no any font shown
I display tga in photoshop then change it to png
I use the svn binary in window.
I follow orx development for some time.
I tested the new orxFontgen from svn and it works on windows 7 64bit, with Matterhorn.ttf and the 26 standard latin characters.
EDIT: FYI: I used Imagemagick to convert to png.
@laschweinski Your picture looks a lot like what happens when an image viewer doesn't know how to deal with TGA files that contain an alpha channel. What is the viewer you used for the conversion? Have you tried with something like xnview (free viewer/converter at http://www.xnview.com)
then after use the convert is ok now.
I haven't opened tga before in win xp.
most of time I am in ubuntu.
I'll check that in later today.
the width between the letter have been solved, but the letter height still has error.
as the picture I paste below
it seems all letter are aligned to the top line rather than the base line. it seems need a height params for every letter to present y of baseline.
Can you provide me with the .ttf you used?
I have tried Matterhorn.ttf is ok ths position of the baseline is corrected.
I am wondering what is the difference between the two formats.
That will produce very different results, unfortunately.
I'm having one problem:
since I use non monospaced fonts I get extrem spaces inbetween words, where there should only be a single space character. In the CharacterWidthList the width for the space character is: 278, when CharacterHeight is 128.
I'm not sure if I'm supposed to add a space to the list of characters. but even if I don't theres a huge space inbetween words.
that's the font I'm using:
You have to define the space characters, for sure, otherwise orx doesn't know what to display and it'll just leave a hole (not sure if the length is arbitrary or simply the same as the widest defined character).
What command line parameter did you use?
The space size should be the one defined in the font even if you don't provide the -a parameter. By default, if a glyph doesn't draw anything (usually the space character) I'll get its metrics from the font to know how wide it is supposed to be. It's only if I don't find that info that I'll use the widest character's size as value here.
I'll test it on my side tonight to see how it behaves.
I guess you can not declare the space in the list of characters, and add manually at the end of your bitmap (if you're luck in the extra padding there enough space for it so you only need to add it to the 2 config lists). If there isn't enough space at the end of the last line, you'll have to add a full new empty line in your texture but that would be very unlucky.
the ini file looks like:
however when running the problem this character list will be trimmed to
Trailing spaces in config block values will now be conserved and the solution described above should now work for you (I successfully tested it with a custom font here).
Let me know if you have another issue.