Flickering issues in release mode

[Ats]

Hello,
Omeganaut is flickering like crazy when objects are at a distance of 100 to 500. And the objects are quite big and distant one from another, so it shouldn't happen like that. Here's how it looks:
https://gemoo.com/tools/upload-video/sh ... 2319210496

The problem is also very visible on the buildings that are intersecting the hill slopes.

So I tried a lot of things to repair that:

• Adjust clipNear/clipFar
• Use glhint to try to correct the perspective:

Code: Select all

const int GL_PERSPECTIVE_CORRECTION_HINT = 0x0C50;
const int GL_NICEST = 0x1102;
const int GL_FASTEST = 0x1101;
void glHint(int target, int mode){}

glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);

• Play in different game resolution, fullscreen or windowed, and on different devices
• Try things with models' RenderOrder
• Change shader's precision to highp
• ...

When I discovered something weird: it works perfectly in preview mode!
https://gemoo.com/tools/upload-video/sh ... 1716768768

So I wonder if the preview mode is rendering things differently than the release mode... Is that possible?

Edit for precision:

• Both videos were taken on the exact same computer
• Flickering happens on every devices (computer or android) in release mode
• No flickering happens in preview mode, regardless of the computer

[VilleK]

@Kjell do you have an idea? Maybe the preview is using a depth buffer that is configured differently.

[Ats]

I made a very simple example. Though I am not sure if this is the same problem, since the example is very basic, all while my game is using ES2/GL3+shaders+cameras, you can see the thing doing weird stuff in release mode, while it works fine in preview. The farther the distance from the camera, the bigger the problem:

Preview:

Screenshot 2024-04-19 155458.png (3.14 KiB) Viewed 239 times

Release:

Screenshot 2024-04-19 155510.png (4.05 KiB) Viewed 239 times

Code: Select all

<?xml version="1.0" encoding="iso-8859-1" ?>
<ZApplication Name="App" Caption="ZGameEditor application" CameraPosition="0 40 -56.5882" ClipFar="500" FileVersion="2">
  <OnUpdate>
    <ZExpression>
      <Expression>
<![CDATA[time += App.DeltaTime;
App.CameraPosition.Z = cos(time)*100;]]>
      </Expression>
    </ZExpression>
  </OnUpdate>
  <OnRender>
    <RenderTransformGroup Translate="0 0 -200">
      <Children>
        <RenderMesh Mesh="MeshBox"/>
      </Children>
    </RenderTransformGroup>
    <RenderTransformGroup Translate="-50 0 -200" Rotate="0.05 0 -0.2">
      <Children>
        <RenderSetColor Color="1 0 0 1"/>
        <RenderMesh Mesh="MeshBox"/>
      </Children>
    </RenderTransformGroup>
    <RenderTransformGroup Translate="50 0 -200" Rotate="0.1 0 0.1">
      <Children>
        <RenderSetColor Color="0.502 1 0.502 1"/>
        <RenderMesh Mesh="MeshBox"/>
      </Children>
    </RenderTransformGroup>
  </OnRender>
  <Content>
    <Mesh Name="MeshBox">
      <Producers>
        <MeshBox Scale="200 5 200"/>
      </Producers>
    </Mesh>
    <Variable Name="time"/>
  </Content>
</ZApplication>

[VilleK]

I made a very simple example. Though I am not sure if this is the same problem, since the example is very basic, all while my game is using ES2/GL3+shaders+cameras, you can see the thing doing weird stuff in release mode, while it works fine in preview. The farther the distance from the camera, the bigger the problem:

I'm not getting that difference here. Are you using the latest ZGE update from this year?

I've checked and preview and release are both using 16-bit depthbuffer so that should not be the issue.

[Kjell]

...

@Kjell do you have an idea? Maybe the preview is using a depth buffer that is configured differently.

I had no idea ZGE was (still) requesting a 16-bit depth buffer Anyway, the editor gets a 24-bit depth buffer for some reason, while standalones do get a 16-bit depth buffer ( on some systems ) as requested. Maybe it's time to leave 2001 behind and request / use 24-bit by default?





Depth values retrieved using DescribePixelFormat.

K

[Ats]

I'm not getting that difference here. Are you using the latest ZGE update from this year?

My ZGE version is new, but since the folder where I unzipped it is shared with Dropbox between my computer and laptop, there might be remnants from an older release causing issues. So I tried downloading a fresh copy of ZGameEditor, but the flickering problem persists.

Anyway, the editor gets a 24-bit depth buffer for some reason, while standalones do get a 16-bit depth buffer ( on some systems ) as requested

Yeah! Trying to fix this bug in my shaders code was making me anxious after all this time

I'm not sure if a 16-bit buffer is outdated, but if it dates back to 2001, there probably aren't many devices still working to use it. Perhaps an option to choose between 16 and 24 would be helpful? Same as legacy and ES2/GL3. I don't know.

[VilleK]

I had no idea ZGE was (still) requesting a 16-bit depth buffer Anyway, the editor gets a 24-bit depth buffer for some reason, while standalones do get a 16-bit depth buffer ( on some systems ) as requested. Maybe it's time to leave 2001 behind and request / use 24-bit by default?

Good idea . I've now updated the code to request 24-bit depth buffer. Please try the latest version.

[Ats]

have Thanks, it's working perfectly on Windows. Though, I had to deactivate Windows Defender because the new ZGameEditor.exe is triggering the antivirus like old time...

I need to set a few things in order to compile the new libzgeandroid.so and Player_linux.bin files. But I'll post them when it's done and I have verified that they work too.

[Ats]

While I was setting up the Android development stuff, I noticed that, in GitHub, you modified:

Code: Select all

Build/android/java/src/org/zgameeditor/Zge.java
setEGLConfigChooser(8, 8, 8, 8, 24, 0);

Yet, in the new zip of ZGameEditor, it is still in 16 bits:

Code: Select all

ZGameEditor\Android\Template\4.1\src\org\zgameeditor\Zge.java
setEGLConfigChooser(8, 8, 8, 8, 16, 0);

[Kjell]

Hi Ats,

I'm not sure if a 16-bit buffer is outdated, but if it dates back to 2001, there probably aren't many devices still working to use it. Perhaps an option to choose between 16 and 24 would be helpful? Same as legacy and ES2/GL3. I don't know.

It's outdated yes. The RIVA TNT from 1998 already supported a 24-bit depth buffer. But in the first couple of years the bandwidth you saved by using a 16-bit depth buffer could make quite a difference on performance. On the mobile side of things it's a bit different .. in the Android SDK 16-bit is still the default afaik.

And just to show that even with 24-bit you need to keep your clipping range in check





K

[Ats]

Here's libzgeandroid.so for Android:

libzgeandroid.zip

(219.88 KiB) Downloaded 20 times

It's working nicely too

I'll finish producing the linux lib tomorrow, as I can't simply svn checkout ZGameEditor on GitHub, and I don't know why...

[Ats]

And just to show that even with 24-bit you need to keep your clipping range in check

Thanks for the heads-up, Kjell!
I always wondered why the planets with rings had severe z-order problems (but not on NVIDIA video cards). Turns out that the camera filming them is ranging from ClipNear 0.1 to ClipFar 10000.0
I'm going to work on that.

Anyway, here's the newly compiled Player_linux.bin file. I had to modify my compilation tutorials because GitHub dropped svn checkout, and replace it by git clone. An easy fix, for a change!

Player_linux.bin.zip

(239.35 KiB) Downloaded 9 times

[Kjell]

Hi Ats,

I always wondered why the planets with rings had severe z-order problems (but not on NVIDIA video cards).

It's not really NVIDIA related / exclusive. When ZGE ( or a standalone made with ZGE ) boots it requests a pixel format for the OpenGL context from the OS. This is only a request though, depending on the OS / GPU / drivers you might get exactly what you asked for .. or in case it's not supported, something as close to your request as possible ( in which case it tries to give you something better if available ).

So with ZGE requesting a 16-bit depth buffer, the "best" outcome would be that you get a 16-bit depth buffer. But since 32-bit color + 24-bit depth ( + 8-bit stencil ) is pretty much the standard these days i guess it's not uncommon that you get a 24-bit depth buffer instead of 16-bit.

Turns out that the camera filming them is ranging from ClipNear 0.1 to ClipFar 10000.0

You always want to make your clipNear value as big as possible and your clipFar value as small as possible

K