#32 Change fonts to use single more space-efficient image files

[qubodup]

Create separate font files as discussed on https://sourceforge.net/p/trigger-rally/discussion/527953/thread/b362438f/?page=3 and https://sourceforge.net/p/trigger-rally/discussion/527953/thread/e84721b6/

[qubodup]

Here are two versions of both fonts, each with a debug-colored version.

The ones with "Waste" in them have the old margins, which waste a lot of space.

[qubodup]

PS: in response to

This is because the new font has a higher center point compared to the previous font.

Isn't this fixable by centering the fonts in the PNG instead of compensating for it in code?

As we can see in https://sourceforge.net/p/trigger-rally/feature-requests/_discuss/thread/24bc90db/dcd1/attachment/fontDsmNormalColored.png some characters got up to the bottom, others go up to the top. We have to move all characters equally to preserve the baseline. So in the end we can't change the center any more in the font.

[Andrei]

As we can see in https://sourceforge.net/p/trigger-rally/feature-requests/_discuss/thread/24bc90db/dcd1/attachment/fontDsmNormalColored.png some characters got up to the bottom, others go up to the top. We have to move all characters equally to preserve the baseline. So in the end we can't change the center any more in the font.

I do not understand what you're trying to say. Have you implemented code support for the fonts and reached the conclusion that centering them is useless?

As for the "condensed" version, I am a bit sad to see that you all but abandoned the idea of shadowy fonts, given how much the horizontal space is reduced.

Also can't you stretch the condensed version so that there are no bottom and right margins? If you don't do this the code will have to account at least for the bottom margin: to my knowledge texture coordinates start bottom-left (0,0) and move up to top-right (1,1).

[qubodup]

I do not understand what you're trying to say. Have you implemented code support for the fonts and reached the conclusion that centering them is useless?

By maximizing the space usage of the font, we make it as big as possible, so that still each character fits into the box while keeping the same baseline (the floor on which each font stands). I just meant that the 0.02f repositioning is necessary if we want to maximize space usage efficiency.

As for the "condensed" version, I am a bit sad to see that you all but abandoned the idea of shadowy fonts, given how much the horizontal space is reduced.

Not at all. The old font had no vertical spacing so we couldn't get any additional benefit from the horizontal spacing anyway. I intend to make a shadowed font once it's clear whether we can use the new layout or if we have to stick to the old one. The method for making it would be to reduce the white font size (just like the outlined white font is smaller) and use the space made available that way for the shadow.

I don't actually understand how we could use the additional margin for shadow. I'm sure the shadows of two fonts overlaying would create artifacts.

Also can't you stretch the condensed version so that there are no bottom and right margins? If you don't do this the code will have to account at least for the bottom margin: to my knowledge texture coordinates start bottom-left (0,0) and move up to top-right (1,1).

Very good that you point this out! The color markers are actually guidelines for us where the fonts can be drawn but the space which has to be used by trigger is +1px on each side to prevent texture bleeding. So while the area in which we can draw "a" is x1=1, y1=1, x2=42, y2=63, the area that should be used to draw "a" on the screen is x1=0, y1=0, x2=43, y2=64. For "b" the drawn area is x1=42, y1=0, x2=85, y2=64.

[Andrei]

I intend to make a shadowed font once it's clear whether we can use the new layout or if we have to stick to the old one.

I'll start to implement the new drawText() function as soon as you provide the final, margin-less square image font. Just to make sure there are no misunderstandings: I would want all margins of the texture (left, right, top, bottom) to be one pixel and no more.

[qubodup]

I thought what I made was final but I realized that re-using 1px border makes no sense because pixel bleeding happens when the neighbor pixels are non-transparent, forcing us to use 3px margins effectively.

Here is a version where each font is 42x63 for the programmer (but for the texture maker it is 40x61, because each character needs a 1px margin but it also needs the neighbor characters to have a 1 px margin.

[Andrei]

Can the black-and-white margin (as shown in attached image) be removed while keeping the texture 512x512?

[qubodup]

The space used is square, so yes. However now the character area boundaries and margins are decimal numbers now. Can OpenGL cut images that way effectively?

[Andrei]

The space used is square, so yes. However now the character area boundaries and margins are decimal numbers now. Can OpenGL cut images that way effectively?

Yes it can and thanks, you simplified my work. To clarify about the decimals: OpenGL considers the entire texture to fit in a 1x1 square, so the coordinates of all characters will be in the interval [0,1] anyway.

One thing I've observed: the "natural" font aspect ratio of your font (8/12=0.666) doesn't work well for the menu: the characters have too much space in between them, so I had to revert to the original 0.6f aspect, which trims the fonts horizontally. This isn't a font problem -- it's a menu problem, and we should go back to 8/12 eventually.

Here's the current source code attached, with the new drawText() function in src/pengine/render.cpp. You must use your new "zoomed" square font as "consolefont.png" and also the PTEXT_ALTSTYLE flag is as of now deprecated.

MD5 sum:

f8755c25490be6982d714e087129abea  src-0.6.3-squarefonts.zip

[qubodup]

Glad to see it work!

I made 1024x1024 versions, the scaling was a bit to noticeable, already at 1280x720 resolution.

Feel free to pick the name. I would vote for not using "console" in the name (I think it was based on the font style or something) and I would suggest fontDsmOutlined.png etc. and to not have nummerical indexes but whatever floats your boat. :)

By the way, using the old font is quite fun:
http://i.imgur.com/ANziB3v.jpg
http://i.imgur.com/IzCoy4x.jpg
http://i.imgur.com/sJOvjrr.jpg

[Andrei]

I am fine with the current names. In the game code, the font objects will be named tex_fontDsmOutlined and tex_fontDsmNormal.

EDIT: I modified the function PSSRender::getTextDims() just below PSSRender::drawText() to use a font aspect of 8/12. Now the "natural" font aspect works fine for the menu as well. The extra space will go together well with the shadows when you get to implement them.

I'll upload the new working directory after I'm done integrating the new textures.