No window contents displayed on Fedora 36 (Beta_22_4)

[wyykak]

Describe the bug BOTH official release and self-compiled version won't display anything in the window (except for the background).

To Reproduce Steps to reproduce the behavior:

1. clone the source
2. change OPENSSL_USE_STATIC_LIBS to false
3. cmake & make
4. run

Expected behavior The initial text input for player's name.

Screenshots

Desktop (please complete the following information):

• OS: Fedora
• Version 36
• Active Mods None

Additional context gcc 12.1.1 cmake 3.22.2 Qt 6.3.1 KDE Plasma (Wayland with Xwayland support)

[Robosturm]

Do you see something during the initial loading e.g. something like this?

[Robosturm]

If yes you may try to add some debug prints to the function void GameWindow::paintGL() in the file gamewindow.cpp to see if the rendering gets called. During the loading screen the screen gets updated directly and afterwards gets triggered via timer my first guess would be that something goes wrong in one of those steps. Either cause qt doesn't trigger an opengl-update doesn't call paintgl or something gets locked here.....

[lonewolf19991]

It's the same issue I have in Debian Bullseye. #988 Is probably the same issue. Same happens with Version 23 of the game. Might be worth it to check the changes that happened between V22 and V23 in terms of GUI functions.

[wyykak]

Do you see something during the initial loading e.g. something like this?

I only see the background, without the text or the progress.

[lonewolf19991]

This is what it looks like, for reference.

[wyykak]

just like the screenshots in lonewolf's comment

[lonewolf19991]

I ran some tests under Manjaro (which has qt 6.3.1 easily available) and I can confirm, up to version 22.7 the game runs properly, however after version 23 onward, it displays the error of the screenshots. I tried changing the log level in the ini file just in case, and there are no reports of any errors. I believe it might be best to search as Robosturm suggested and then do a pull request with the solution.

[Robosturm]

I went through the commits and the only commit i would say that changes something related to rendering is this one: 9a47fb56b2a621d122d1f758644c8a3bc2fbc546 Could you test if it worked before that commit and break afterwards?

[Robosturm]

You could also try if the function bool Actor::onScreen(RenderState& rs) in actor.cpp return's false and see what bounds it uses. My guess is that the commit somehow destroyed the clipping function on linux. Since it works fine on windows and android.

[Robosturm]

I thought about the code and my guess is that qt's devicePixelRatio() returns 0 on linux devices which would set the screen device to 0 and clipp everything that's not at the position of 0/0. I'm adding a pre emptive check to this part in the next commit

[Robosturm]

Last commit changes the active dpi factor to 1 in case it's 0, which may fix the issue. @wyykak @lonewolf19991 you could try to use that commit to see if it fixes the issue As mentioned it's my best bet on what's going wrong

[wyykak]

It does not work for me, still no contents in the window.

[wyykak]

change Actor.cpp:917 to return true; will fix the problem

BTW, there will be shader error in debug mode.

[wyykak@fedora build]$ ./commander_wars 
Warning: QOpenGLShader::compile(Vertex): 0:1(8): error: syntax error, unexpected end of file
 ((null):0, (null))
Warning: *** Problematic Vertex shader source code ***
#version 110
#define lowp
#define mediump
#define highp
#line 1

*** ((null):0, (null))
Critical: can't compile shader. Log:
0:1(8): error: syntax error, unexpected end of file
 (/home/wyykak/codes/Commander_Wars/3rd_party/oxygine-framework/oxygine/core/ShaderProgram.cpp:74, void oxygine::ShaderProgram::compileShader(QOpenGLShader&, const QString&))
Warning: QOpenGLShader::compile(Fragment): 0:1(8): error: syntax error, unexpected end of file
 ((null):0, (null))
Warning: *** Problematic Fragment shader source code ***
#version 110
#ifdef GL_KHR_blend_equation_advanced
#extension GL_ARB_fragment_coord_conventions : enable
#extension GL_KHR_blend_equation_advanced : enable
#endif
#define lowp
#define mediump
#define highp
#line 1

*** ((null):0, (null))
Critical: can't compile shader. Log:
0:1(8): error: syntax error, unexpected end of file
 (/home/wyykak/codes/Commander_Wars/3rd_party/oxygine-framework/oxygine/core/ShaderProgram.cpp:74, void oxygine::ShaderProgram::compileShader(QOpenGLShader&, const QString&))
Warning: QOpenGLShader::link: error: linking with uncompiled/unspecialized shadererror: linking with uncompiled/unspecialized shader ((null):0, (null))
Fatal: 13.08.2022 21:20:20: can't compile program: error: linking with uncompiled/unspecialized shadererror: linking with uncompiled/unspecialized shader (/home/wyykak/codes/Commander_Wars/coreengine/console.cpp:226, static void Console::print(const QString&, eLogLevels))

[lonewolf19991]

I will try @wyykak 's solution as well in the meantime. And report back if it's also solved.

[Robosturm]

@wyykak you're debug installation is damaged it doesn't contain the resource folder at the correct folder. You can fix that by changing the occurange of set(DEPLOY_RESOURCES_AS_FOLDER true) at the start of cmake to set(DEPLOY_RESOURCES_AS_FOLDER false) It results in longer linking times which is why i disabled it for debug builds.

[Robosturm]

@wyykak Can you tell me what the values of the variables float width = oxygine::Stage::getStage()->getScaledWidth() + safetyArea; float height = oxygine::Stage::getStage()->getScaledHeight() + safetyArea; in the function are?

[wyykak]

@Robosturm 10 & 10 always

[Robosturm]

My guess now is that it's a runtime issue and windows and android are slow enough.... I'll add something which fixes the potential runtime issue that i have in my mind @wyykak @lonewolf19991 I updated the code so that the stage size gets updated correctly when it's initially created. Currently i think there's potential runtime issue during the booting phase where the stage isn't created but the window size gets changed which leads to the stage not getting the new window size. Thus thinking the screen size is 0. Could you try the new commit, it should fix the issue

[wyykak]

I tried the latest commit, it looks good. Width and height value are correct and contents are rendered.

[lonewolf19991]

I tried latest build, it rendered properly after making the changes @wyykak suggested.

[Robosturm]

@lonewolf19991 Wyykak suggestion is a workaround which potentially highly decreases the performance of the game, so i recommend using my latest commit without changes since it solves the actual issue and isn't a workaround ;)

[lonewolf19991]

Confirming just in case. The latest build 0.24.3-dev, with the latest commit displays all GUI elements properly.