Jump to content

[FIXED] Font display problem on armv7 harfp


barc65
 Share

Recommended Posts

It's strange that some work and some don't.

Our fonts are actually textures (see http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/mod/fonts), and regions of these textures are just used to make a text.

We use PNG textures in the SVN version, but these get converted to a dds for distribution (and also for rendering). So it would be interesting to know if you use the SVN data, or the distributed data.

It would be interesting to know which fonts work, and which don't. Maybe the problem starts when the files reach a certain size.

This is the XML file defining the start-page: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/gui/pregame/mainmenu.xml Could you modify it a bit, and test with different fonts?

Link to comment
Share on other sites

I don't have sans-bold-stroke 16, so I don't think that exists.

But I think I found the issue, and it's not an ARM issue. It looks like you're able to render all stroked fonts, and these are exactly the fonts that are rendered in the RGBA colour space. The non-stroked fonts are rendered in greyscale (to save memory). You can see it in the fontbuilder: http://trac.wildfiregames.com/browser/ps/trunk/source/tools/fontbuilder2/fontbuilder.py (see the font list at the bottom)

So there would at least be a rather simple workaround for the fonts: build all fonts in RGBA. This is as simple as adding "colour":True to line 189, and rebuilding the fonts.

But that's not even needed. Ben / Historic_Bruno changed something to texture handling recently: http://trac.wildfiregames.com/changeset/16439

And what do we see now? Everyone with an existing installation will not have a problem (because the png textures are cached to dds), but everyone with a new installation will see broken greyscale fonts :D

So I guess I'll ask Ben to fix it. It won't take long before we get new complaints.

Thanks for the report.

Link to comment
Share on other sites

As you can see behind, there's "stroke" fonts in my installation ;-)

The problem is now resolved with your little patch. Thanks very much for your support.

jetson% python fontbuilder.py
mono-10...
mono-stroke-10...
sans-9...
sans-10...
sans-12...
sans-13...
sans-14...
sans-16...
sans-bold-12...
sans-bold-13...
sans-bold-14...
sans-bold-16...
sans-bold-18...
sans-bold-20...
sans-bold-22...
sans-bold-24...
sans-stroke-12...
sans-bold-stroke-12...
sans-stroke-13...
sans-bold-stroke-13...
sans-stroke-14...
sans-bold-stroke-14...
sans-stroke-16...

Link to comment
Share on other sites

Thanks for troubleshooting that, Sander :) I had wrongly assumed that all the textures were handled the same way, but fonts are a strange exception. I don't know why the texture type is stored in the metadata instead of using the properties from the PNG image. One solution is to not convert all grayscale images to RGB (fonts might be the only such textures we have now), which I added as a workaround for grayscale PNG loading, but now that I test, #1640 no longer occurs for me. I'll continue testing.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...