[BUG] [Duke 3D] GLES2 rendering broken

[dhwz]

Raze version

No response

Which game are you running with Raze?

Duke Nukem 3D

What Operating System are you using?

Other

Please describe your specific OS version

Linux ARM

Relevant hardware info

RK3399, RK3326 with MALI GPU (GLES2)

Have you checked that no other similar issue already exists?

• [X] I have searched and not found similar issues.

A clear and concise description of what the bug is.

somewhere between commit 3242b8fd81927b650e1a35554e3b931dec46bc1a and bd6b0eaac563cab26d041a4095126f2e0186aa09 the GLES2 renderer got badly broken. While walking around in Duke Nukem 3D the textures are just disappearing.

Steps to reproduce the behaviour.

Explain how to reproduce

Your configuration

No response

Provide a Log

No response

[coelckers]

I am unable to reproduce the problem on my desktop system with any of the 3 backends, so I'm going to need help here narrowing it down. Can you try compiling a few commits between these two points and check where things start to break down?

[dhwz]

Yes of course, I'll try to narrow it down to a specific commit.

[dhwz]

@coelckers it's working properly up to this commit 3242b8fd81927b650e1a35554e3b931dec46bc1a. After that commit I can't compile till bd6b0eaac563cab26d041a4095126f2e0186aa09 fixed the compile issues on Linux.

I'm suspecting on of these commits between where biangle was changed to DAngle is breaking it, probably not only on Duke engine, thats just the one I've tested it on.

Just FYI, this patch is applied as else raze doesn't work on my SoC:

index 5d82511b6..8b922dbc5 100644
--- a/source/common/rendering/gles/gles_system.cpp
+++ b/source/common/rendering/gles/gles_system.cpp
@@ -12,6 +12,7 @@ EXTERN_CVAR(Bool, gl_customshader);
 void setGlVersion(double glv);

+#define __ANDROID__
 #if USE_GLES2

 PFNGLMAPBUFFERRANGEEXTPROC glMapBufferRange = NULL;
@@ -183,6 +184,7 @@ namespace OpenGLESRenderer
 #if USE_GLES2
                gles.depthStencilAvailable = CheckExtension("GL_OES_packed_depth_stencil");
                gles.npotAvailable = CheckExtension("GL_OES_texture_npot");
+               gles.useMappedBuffers = true;
                gles.depthClampAvailable = CheckExtension("GL_EXT_depth_clamp");
                gles.anistropicFilterAvailable = CheckExtension("GL_EXT_texture_filter_anisotropic");
 #else
diff --git a/source/common/rendering/gles/gles_system.h b/source/common/rendering/gles/gles_system.h
index f884d4593..1ca2554ac 100644
--- a/source/common/rendering/gles/gles_system.h
+++ b/source/common/rendering/gles/gles_system.h
@@ -23,7 +23,7 @@
 #include <sys/stat.h>
 #include <fcntl.h>

-#define USE_GLES2 0 // For Desktop PC leave as 0, it will use the exisiting OpenGL context creationg code but run with the GLES2 renderer
+#define USE_GLES2 1 // For Desktop PC leave as 0, it will use the exisiting OpenGL context creationg code but run with the GLES2 renderer
                     // Set to 1 for when comipling for a real GLES device

 #if (USE_GLES2)

[Halcyon522]

If it helps, I can confirm the same issue on my raspberry pi.

Edit: Again, if it helps, I compiled the last stable version 1.4.1 and the issue isn't there.

[coelckers]

1.4.1 is way too old, We need checks between the two commits linked in the post above by someone who can temporarily fix the code to compile again.

[Halcyon522]

Agree absolutely. I'm not a developer, just an interested party. I really appreciate your work!

[dhwz]

@coelckers that is unfortunately beyond my capabilities Hope someone else who can reproduce the issue can help

[Chatplosion]

This seems to be an error related to ARM64 based systems only. I have it on my Hardkernel N2+ too. The ARM fraction is the most complicated with its unique design. Maybe developers should buy ARM64s too. My version is 1.6pree-1999-g5ebf2fef89.

[mjr4077au]

This seems to be an error related to ARM64 based systems only. I have it on my Hardkernel N2+ too. The ARM fraction is the most complicated with its unique design. Maybe developers should buy ARM64s too. My version is 1.6pree-1999-g5ebf2fef89.

We probably should buy a PPC and Loongson setup as well, yeah? Surely you can't expect us to own hardware of all architectures to debug such edge cases?

I mean, I'll take one for free if you're offering? I'm in Sydney, Australia 🙂

[Halcyon522]

I'd happily send you an RPI 4 if they weren't so damned hard to get right now.

[mjr4077au]

What someone needs to do is create a branch at 3242b8fd81927b650e1a35554e3b931dec46bc1a where the issues hadn't started, start cherry picking each commit above it one-by-one, fixing the constexpr issues so that it builds and let us know precisely where it breaks.

The issue is probably somwwhere in the code that changes the clipangle or bunch drawer stuff, but it all works fine on Windows and Linux so we can't test much further than that.

[emileb]

Just seen this. Yes this most likely something to do with ARM, I remember ZDoom has something similar to do with converting angles and clipping, something about technically undefined behaviour. When I update Zeta Touch I think I will face the same issue and can take a look then.

[emileb]

Found it, maybe related? https://www.doomworld.com/forum/topic/72804-zdbsp-output-incorrect-on-arm-processors/

[coelckers]

I think that old issue has long been addressed. Not sure if such karge numbers can come through this code in Raze

[Chatplosion]

With the newest Version from master branch it is impossible to start whatever game you want. It freezes with a fullscreen window. Nothing is working. Clearly a GL/GLES problem.

[mjr4077au]

Our lovely @madame-rachelle has addressed this in 6b8bdcc449210092fed874f10fe8af928ab89fc8. Please let us know if there's any further issues.

@Chatplosion, since your issue is reported against GZDoom as well, a fix there will fix it here as well. If you want one open in this project, feel free to open another one as your problem isn't directly related to this.

[coelckers]

My problem with this code is that no longer can perform const conversions. I think a better fix would be to first cast to 64 bit ints before truncating to 32 bit. Such code can be resolved at compile time and still be robust enough againt too large values

[madame-rachelle]

Can you be more specific? This was a solution that myself and mjr collaborated in order to provide a band-aid fix for the issue, as I understand it the long-term goal is to eliminate binangles completely and use normal radians and vectors like GZDoom does.

Were you looking for something like ... return angle_t(int64_t(rad * (0x80000000u / M_PI))); ?