SFML community forums
Help => Graphics => Topic started by: MJBrune on July 04, 2018, 03:13:27 am
-
So first off the direct issue can be seen in the following image:
(https://i.imgur.com/Ojo5Cuq.png)
The issue is that the letter K is instead just jumbled. This happens rarely and maybe once every 20 game launches.
The game has a font manager singleton that holds an sf::Font currentFont and is loaded via loadFromFile from the options singleton that I have in the game. So reloading the font fixes this issue. Each state's SF::Text's loads the font once, on their construction.
So is it possible for like the glyph in memory to move and thus for this to happen because a glyph is pointed at garbage?
Thanks
-
If it's more or less easily reproducible, would be interesting to see what getTexture on the font returns. What's the hardware spec you run this on? Maybe sometimes it runs out of VRAM? What does sf::Texture::getMaximumSize() return?
-
Thanks for the response!
I'm seeing this on Fedora 27 and 28 running proprietary Nvidia drivers and a GTX 1070. MJBrune is running some flavour of Windows. I haven't seen it on our Mac builds, but to be honest, we spend less time playing/testing that, and it's an easy thing to miss since it's usually only one character (in the screenshot, I think that's an upper case K - every upper case K will be like that until the font is re-loaded or the game is re-launched), and doesn't always stand out as much as it does in the screenshot.
We've been chasing this one for about a year now but haven't had much luck in narrowing down what's going on. It's a tricky one in that it occurs maybe once in 20 - 40 launches of the game, but we'll try to see if we can get some more info.
-
What version of SFML are you using?
-
2.5.0 (pretty sure it's the official release codebase modified to address this issue (https://en.sfml-dev.org/forums/index.php?PHPSESSID=qumsn44ggumsmr9c9h5l5s7ug0&topic=24127.0) with WAV file loading), but we've seen it happening as far back as 2.3.2.
Still working on getting that extra information you asked for. I've been focusing on art stuff lately and haven't been running the game frequently enough to have much likelihood of seeing it.
-
I haven't managed to get the texture when it's happened yet, but sf::Texture::getMaximumSize() on my machine returns 32768.
The texture that is generated when things are behaving is 128x128.
-
Finally managed to catch this, and it looks like the texture itself is getting smashed too. In this case, upper case M and K are borked (and possibly other characters - hard to say).
(https://imgur.com/vKmRWc3.png)
(https://i.imgur.com/Ia3Of5m.png)
The metrics for the busted glyphs are off - note that advance (how much distance there should be before the next character is displayed) on the M is about 3 pixels, and not the 7 pixels seen for the correct upper case M in the screenshot in the first post. I've also seen instances where advance, width and height are all larger than they should be on a corrupted character.
Best guess is that this happens before/during glyph construction?
-
Can you share the font file? Or is it purchased? I'm not sure this is a texture issue.
-
I'm not sure on the specifics of where that font came from/how we're licenced to redistribute it (MJBrune can speak to that), but it's definitely not that font file. We've seen it happen with multiple fonts, and the game runs without corrupted text more often than not with all of the fonts we're shipping.
Here's what that one looks like when everything's behaving normally.
(https://i.imgur.com/J5byvWB.png)
-
Could you name the fonts used? Just trying to narrow it down.
Edit:
Comparing both textures, the glyphs are arranged differently. Any chance the issue appearing/disappearing is related to the order of glyphs being used?
-
Sure, we've seen it with monoflur (used in the screenshots in this thread), one of the monospaced opendyslexic variants, and a font called GTFO (which is not Pixels Or GFTO).
-
See my addition above: Comparing both textures, the glyphs are arranged differently. Any chance the issue appearing/disappearing is related to the order of glyphs being used?
-
I don't believe so. My impression from observing this bug over the past year is that we can run the game twice from the same save, load the same things, and one time it might be busted, and the next not. Edit: Of course, it happens so rarely that I might only see it once a month, so it's been hard to get a solid feel for.
This feels enormously difficult to test for since I'm yet to be able to reliably intuit character load order from texture packing.
-
I added a quick hack in yesterday to (hopefully) make glyph loading order/the point at which they're loaded consistent. This also removes potential multithreading causes (I don't *think* there are any, but the point of unknown problems is that you don't know, so I don't want to rule anything out) from the equation.
Can't really say how long it'll be before we're confident of whether or not that's had an impact at all, but in the meantime, I'm happy to try to provide any other infomation that might be relevant.
-
What really confuses me is the fact that not only your glyphs are somehow mangled, they're also not using the correct dimensions/alignment. As such I still think it's some weird issue in Freetype rather than SFML. Not 100% sure though.
-
You mentioned threads? Do you use Font in few? getGlyph is marked as const but it can do modifications and it's not threadsafe.
-
What really confuses me is the fact that not only your glyphs are somehow mangled, they're also not using the correct dimensions/alignment. As such I still think it's some weird issue in Freetype rather than SFML. Not 100% sure though.
This was my first thought when I encountered it. It's definitely not something I'm willing to rule out, but hopping between Freetype versions and trawling their issue tracker hasn't shown anything that's stood out as relevant to me so far.
You mentioned threads? Do you use Font in few? getGlyph is marked as const but it can do modifications and it's not threadsafe.
We assign the font to Text variables (via sfe::RichText (https://github.com/skyrpex/RichText)) outside of the main thread, but we do the actual rendering in the main thread. From what I understand of how SFML's font class works, new glyphs are loaded as part of draw() calls rather than during font/string assignment (it's another possibility I don't want to rule out, though).
-
Getting bounds of sf::Text triggers a rebuild too and you seem to be doing that in RichText::Line::updateTextAndGeometry which is called by RichText::Line::updateGeometry (and in appendText) which is called after setting style, color, font, etc. in a Line (which are called by corresponding RichText functions).
-
Getting bounds of sf::Text triggers a rebuild too and you seem to be doing that in RichText::Line::updateTextAndGeometry which is called by RichText::Line::updateGeometry (and in appendText) which is called after setting style, color, font, etc. in a Line (which are called by corresponding RichText functions).
Ah ha, right you are!
From what I'm reading in the SFML source, it seems like we should only be encountering problems when getGlyph() calls are called outside the main thread for glyphs that haven't already been cached, so my workaround of pre-populating the cache with every character when the font is loaded should get us in the clear for this use-case?
-
Yes, I think so.
-
Cheers. Many thanks for walking through this one with us!