(GLES) Texture flickering , black areas instead of textures

[ClessxAlghazanth]

Using the latest github build from here

https://devbuilds.drdteam.org/gzdoom/gz ... cc5a272.7z

Using open gl-es renderer , I got wall textures disappearing and appearing here and there , flickering of textures , and black areas here and there

Tried with vanilla and a few mods , applies to all

I didn't have this issue with GZDoom-gles 4.6.1 which I've been using so far

.ini file and system details for reference

best regards

[ClessxAlghazanth]

Sorry for double-posting due to attachment limit , here's my .ini file

[Graf Zahl]

I made some changes here. Can you please retest? I was only partially experiencing your issues so I need confirmation.

[ClessxAlghazanth]

I made some changes here. Can you please retest? I was only partially experiencing your issues so I need confirmation.

Thanks a lot for the kind response

Should I download from the same link at drdteam/devbuilds (pre-195 one) ?

[Graf Zahl]

Yes, as soon as the next one becomes available.

[ClessxAlghazanth]

Yes, as soon as the next one becomes available.

Thanks , I tried the latest (today's) github devbuild (pre-197 one) , and while there are less errors , they are not completely gone. I still get flickering & black textures at walls (almost seems random). The overall performance isn't effected (no frame drops or anything)

One thing I noticed that Doom Incarnate's main menu screen bugs out like crazy (which features a lot of smoke & flame with corpses around)
(It could be a good way to check this problem)

I wonder if this is an issue in which some decals not being processed properly ? (Never encountered such issue in GZDoom-gles 4.6.0b & 4.6.1)

Best regards

EDIT : Uploaded 2 short videos to yt demonstrating the issue (sorry for the low quality)

[emile_b]

I finally managed to reproduce this on my machine - it only happens when in full screen on the laptop screen for me. Windowed mode or on an external monitor did not have the problem.

The problem was I didn't have buffer synchronisation when using GLES renderer, this wasn't an issue when HW_MAX_PIPELINE_BUFFERS = 4, but now it's reduced to 2 the engine can 'catch up' with a buffer in use and corrupt the data.

This *may* suggest that having HW_MAX_PIPELINE_BUFFERS higher than 2 might add more performance but I'm not sure.

https://github.com/coelckers/gzdoom/pul ... 66089e0957

[Graf Zahl]

Ok, in this case it may make sense setting it to 4 again. I wanted to avoid that because it inflates several internal data structures.

[ClessxAlghazanth]

Thanks a lot for checking the issue

I did further testing (switching between fs and windowed mode , running on laptop screen - I normally use external monitor) and the issue is always there

I'll test and report again as soon as the next devbuild becomes available

[ClessxAlghazanth]

I just gave pre-204 a shot and voila all the texture glitches are gone ! It works without any noticeable issues so far , and it's great to have most (if not all) the recent updates/fixes while running on fast gles renderer

Not only that , but spotlights behave as they should (I played a round of EVP with it) , can finally use flashlight mods as intended

Thanks to Graf , emile and everyone involved

[Graf Zahl]

Good to hear.
This was one of the last issues standing in the way of 4.7.0. If all goes well it should be out later today.

[Enjay]

Can anything be done about this one before 4.7.0 or is it too much for the next release?

viewtopic.php?f=2&t=70492

[Graf Zahl]

I have no idea how to deal with this without breaking the core guarantee of the GC, i.e. that you can be assured that all pointers to destroyed objects remain valid until execution control reaches the internal main loops again.

[emile_b]

Good to hear.
This was one of the last issues standing in the way of 4.7.0. If all goes well it should be out later today.

Great! Will do a small PR later today if there is still time, it is to check gles.usemappedbuffer = true before using the glSync stuff here:

https://github.com/coelckers/gzdoom/blo ... s.cpp#L235

Also to check the glClientWaitSync function pointers are not null, in case using a very old OpenGL version which does not have them to avoid a crash.