Messages

1

Window / Re: Borderless Fullscreen Windows, sf::Style:None, and Linux Window Managers

« on: September 11, 2018, 03:44:15 pm »

Yeah, a fullscreen borderless window state or automatic checking whether the requested window size matches the current screen mode were the kinds of things I had in mind when saying it needed improvement before it could be merged.

I won't have the downtime to do a test till after The Away Team ships, but looking at the diff for PR #1238, it does not address this issue, which requires the window to be resizeable and _NET_WM_STATE_FULLSCREEN to be set in order for fullscreen borderless windows to behave as I would expect.

At this time, _NET_WM_STATE_FULLSCREEN is only set for sf::Style::Fullscreen, and resizing is disabled before that.

2

Window / Borderless Fullscreen Windows, sf::Style:None, and Linux Window Managers

« on: September 07, 2018, 05:28:26 pm »

Ahoy there!

I recently had to work around item 3 from this thread, where a borderless fullscreen window created via sf::Style::None would not be positioned over the top of launcher bars, status menus and desktop margins in Gnome, KDE, XFCE, and Cinnamon (and probably more). Attached are some screenshots demonstrating various behaviours in various WMs.

After diving down the rabbit hole a bit and doing a bunch of research, I was able to implement something that achieved what I was after without resorting to FSEM (Fullscreen Exclusive Mode), that I've been able to confirm as working with the previously mentioned WMs/DEs.

Best practices for most broadly compatible borderless fullscreen windows seem to include setting _NET_WM_STATE_FULLSCREEN (currently not done for sf::Style::None because sf::Style::None is used for more than just borderless fullscreen windows). In addition to this, the window needs hints saying that it's resizeable before _NET_WM_STATE_FULLSCREEN is set (and then changed to be non-resizeable after) thanks to the fussiness of some window managers. Without these states and hints set in the right order, the WM (Some WMs? Many WMs? All WMs? Who knows) is free to reposition and resize the window to fit the space available to non-fullscreen windows.

The attached patch changes the WindowImplX11::WindowImplX11(VideoMode mode, const String& title, unsigned long style, const ContextSettings& settings) function. It uses the existing sf::Style::Resize resize hints for sf::Style::None, calls switchToFullscreen() when sf::Style::None is used, and moves the "hack" to disable resizing to the end of the function so that it's after switchToFullscreen() calls.

Since the game I'm working on doesn't use sf::Style::None for anything but borderless fullscreen windows, that meets our needs. SFML provides sf::Style::None for other purposes, and so in its current form, I wasn't comfortable opening a pull request. It's also likely to conflict with the work in PR #1238, which appears to focus mostly on FSEM (though what I've learned while writing this patch may still be relevant there).

I am open to improving this patch to a point where it could be merged, but I feel like I won't have time for that in the near future. It's better to share than hoard though, so here it is ^_^

3

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 30, 2018, 01:29:32 pm »

Cheers. Many thanks for walking through this one with us!

4

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 29, 2018, 08:57:40 am »

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?

5

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 29, 2018, 02:31:43 am »

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) 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).

6

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 27, 2018, 11:37:26 pm »

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.

7

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 27, 2018, 02:59:43 pm »

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.

8

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 27, 2018, 02:55:48 pm »

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).

9

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 27, 2018, 02:53:09 pm »

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.

10

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 27, 2018, 02:12:22 am »

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).




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?

11

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 19, 2018, 12:01:33 pm »

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.

12

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 12, 2018, 09:40:05 am »

2.5.0 (pretty sure it's the official release codebase modified to address this issue 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.

13

Graphics / Re: SF::Font - somehow a glyph getting corrupted.

« on: July 07, 2018, 03:18:51 pm »

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.