Radar display bug on android and possible workarounds

[aBlueShadow]

A common display bug on android is the radar bug. There is no grid nor distance circles, the radar shows a black background, and nebulae are not displayed. When this bug is present, it affects all stations with a circular radar, so i.e only engineering, relay and derived stations are fully playable. I am not sure how common this bug is, it is surprisingly rarely mentioned when someone is talking about android, and daid said once on his deviced everything is displayed fine - but it was present on every device I was able to test it on so far.

The obvious difference between relay and the other stations is, that the others are circular, so I changed one to rectangular mode, and suddenly it works:

Looking a bit into the code, it seems that the rendertexture does not work correctly. Instead of using black to cut out a circle, the blend mode seems to be ignored, drawing just a black disc on top of other elements.

EmptyEpsilon/src/screenComponents/radarView.cpp

Line 123 in 277f98c

sf::BlendMode blend_mode(

I have no idea how to fix that (if possible), and as I currently don't have a virtual android setup on my pc, testing is kinda tedious.
A quick workaround would be to add an options.ini switch to change all radars to rectangular. Not a pretty option, but could be beautified a bit, e.g. by changing the background or drawing a rectangular line around the radar. Also, the officer would be able to see a bit more than usual, but I don't think that is a big deal and could be mitigated by letting that option only affect android.

Thoughts?

[daid]

A problem there is SFML's API being an total shitstorm on the blend modes. I didn't know it when I made that code, but it acts like there is a lot of flexibility, but in reality that only works if a specific OpenGL extension in available:
https://github.com/SFML/SFML/blob/519e1f95727b353124fe5c891bc3d1743289463a/src/SFML/Graphics/RenderTarget.cpp#L581

Quite potentially, that is causing the problems.

Note that in your 2nd screenshot, you don't have any areas blacked out by the nebulae fog of war.

[oznogon]

Related SFML forum thread from 2016: https://en.sfml-dev.org/forums/index.php?topic=20969.0

This has been a limitation for years and upstream has no intention of addressing it. Also not all devices/Android OS versions are affected. SFML also doesn't and won't provide the means to detect the absence of those features, so to write around it would require Android-specific code to do so.

Driver-level blend mode compatibility was also an issue with older macOS builds. The workaround then was extensive and half-broken (rewriting radarView to reorder layers and avoid using blend modes) and is no longer necessary on newer SFML/macOS combinations.

[oznogon]

IIRC that workaround involved creating custom PNG frames for radars using the background texture and with a transparent circle in the middle to replace the mask; this wouldn't always align with the background and was especially ugly on the Single Pilot station.

[aBlueShadow]

@daid I assume it just looks that way, because on science, where is more room for that effect, you can clearly see the blackened areas.

[oznogon]

Ah ha, this PR: #327

[oznogon]

Also relevant: issue #168 and PR #557

[aBlueShadow]

Interesting. I was wondering as well, if a transparent image might do the trick. But as that PR was rejected, I guess the same will be true if it is used within android defines instead.

[oznogon]

Resurrected #327 into a branch and replaced the APPLE defines with ANDROID, and it works on an older phone I have that reproduces the same behavior.

https://github.com/oznogon/EmptyEpsilon/tree/android-blend-workaround

Note that the background is missing the crosses, the radar is missing the outer ring and shadow, and the fog of war contrast is less. Without this patch I see the same black background on this device (Nexus 4) as the original report.

[oznogon]

Added APK, DEB, win32 ZIP builds of this branch to https://oznogon.com/ee/ (noblend packages)

[oznogon]

Also it's hilarious and kind of sad gamedev reality that a 3.5-year-old hacky PR, rebased with only a search/replace change, can still fix a SFML problem on up-to-date (if old) Android devices today, 3 or 4 Y-version releases of SFML later

[daid]

Note, a very old version of the code used a stencil buffer instead of the render texture. Maybe that works better for the android version. Disadvantage is that you cannot anti-alias then, there is only on/off control for pixels.

[aBlueShadow]

@oznogen thanks! unfortunately, this causes other glitches on my device (samsung galaxy tab2, which is arguably old, but sufficiently fast imo)


Those are just 2 examples, the look of that glitch seems to be completly random and differs from one session/console to another (e.g. sometimes it is just rgb noise).
Interesting thing is, the science station seems to be unaffected of that glitch, it looks as expected.

[oznogon]

Yes, I saw the same on a 2015 Fire HD 10 yesterday, just haven't had a chance to post it here. However, it also occurred with the 20200115 build without this patch, so I'm not sure if/how it's related.

[oznogon]

The Fire HD 10 uses a PowerVR G6200, and I think the Samsung Galaxy Tab 2 uses either an Adreno 220/225 or PowerVR SGX540 (depending on 7" or 10", Verizon or non-Verizon). Each of those have different known driver issues with shaders, blend modes, and/or depth ordering that might be solved by updates.

My Fire HD 10 will not have any further firmware updates that update the driver, so I cannot confirm.

This does not appear to affect modern devices with updated drivers, although I doubt there's any feasible way to state that comprehensively.

[fiskn]

Is there a possibility we could capture a list of known working tablets? I can confirm that it doesn't work on a 7" Fire tablet, which experiences the corruption bug a few posts up

[oznogon]

I started one in https://github.com/daid/EmptyEpsilon/wiki/Android-device-list — contributions welcome

[fiskn]

Thanks, added 2 devices, will try and get some more tested

[aBlueShadow]

@oznogon I noticed an issue on your noblend-version. It seems to be introduced in EE-2020.08.25. On the science console, the game crashes after selecting the Database. It doesn't crash in the dedicated database station, though.

[oznogon]

If I had to guess, something is probably trying to do 3D rendering that shouldn't.

[oznogon]

Nope; referencing a null object (background_gradient)

01-21 20:57:57.056 19597 19627 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x41d0004c in tid 19627 (id.emptyepsilon), pid 19597 (id.emptyepsilon)
01-21 20:57:57.167 19663 19663 F DEBUG   : pid: 19597, tid: 19627, name: id.emptyepsilon  >>> eu.daid.emptyepsilon <<<
01-21 20:57:57.404 19663 19663 F DEBUG   :       #00 pc 004ab14e  /data/app/eu.daid.emptyepsilon-2itJrC2ggtpEefsgWLK1LA==/lib/arm/libemptyepsilon.so (GuiElement::setVisible(bool)+20) (BuildId: fb489a1c76df23e0f1809ebc74682fbb4f84445a)
01-21 20:57:57.404 19663 19663 F DEBUG   :       #01 pc 004ab165  /data/app/eu.daid.emptyepsilon-2itJrC2ggtpEefsgWLK1LA==/lib/arm/libemptyepsilon.so (GuiElement::hide()+14) (BuildId: fb489a1c76df23e0f1809ebc74682fbb4f84445a)
...

c12352e should fix it

[gcask]

@aBlueShadow given #1413 is in and you confirmed it, do you feel like we can close this?

[aBlueShadow]

@gcask Pretty sure we can. While the first commits produced similar glittches as oznogons patch, you last commit and therefore the PR seems to work fine. Radar looks as expected, all objects and distance circle are visible.
I tested it on 3 different devices, and @StarryWisdom successfully tried https://github.com/gcask/EmptyEpsilon/releases/tag/EE-2021.03.31.radar-stencil-3 which I think has the same fix in it?
So not exactly a big data set, but a very promising one.