Depth issue with ANGLE

[basharast]

Hi,
I was trying to compile N64 core for UWP ARM devices under RetroArch,
and Rice was the only plugin worked perfect
I got only one issue: I guess it's depth issue,

Short Brief

As you know UWP apps need to use ANGLE (by Google) to deal with OpenGLES
and the fact is: ANGLE will do translation from OpenGLES calls to DirectX calls
so expected some issues (textures, depth..etc) specifically with ARM processor
Not to mention the 5 years old documentation at Microsoft page :(
The good thing that Rice doesn't have many issues and it's my only hope for now

Quick note

I used the version that in parallel-n64 core
but I synced a lot of updates from this code here (Including the texture enhancements)

What I need

Due to my limited understanding in OpenGLES I'm testing many things at once but I have no Idea what is the issue exactly
Please take look on the previews below.

• Is this depth issue, or something else?

I know you might be busy so I only need to identify the exact reason of the issue and what code exactly related to it.

What I already tested

• The 'z' value is always gives: 0
• if I enabled Vertex Clipping it will have value but way too big: like 10724841
• If I'm not wrong the g_vtxProjected5 is responsible to handle the dimensions of the vertex list
• Look like GL_DEPTH_TEST is not effective on the 3d objects whatever I use.. nothing changed

Other Plugins

There is GLupeN64 the only one with correct depth but it using GL_DEPTH_ATTACHMENT but I didn't know how to use this with Rice

Manual Vertex Clipper?

I'm not that expert but I found the source of Rice1964 and it contains something called VertexClipper
I hopped it will solve the issue as it will do manual compare and remove the unwanted vertex but didn't work (broke the textures)
I guess because of the main issue -> z=0 or way larger than 1

I really appreciate your help and guide and I'm really tired after 3 weeks looking for solution before posting this issue.

Many thanks.

[poudink]

I seem to be having the same issue on a run of the mill x86-64 laptop with an AMD GPU running Linux (Mesa drivers). Weirdest part is, the exact same thing is happening with Glide64. GlideN64 is completely fine, though.
My mundane hardware seems to rule out a lot of what could be causing the issue in the first post, too. Not UWP, not the ARM CPU, not ANGLE or GLES.
The version of the plugin I used was built straight from this repository, so this should be considered a bug.

[basharast]

After a research I'm almost sure it's happening because there is no depth buffer attached and some GPUs will ignore the depth because of that.
as per the information here: Depth Buffer

In order to use the depth test, the current Framebuffer must have a depth buffer. A depth buffer is an image that uses a depth image format. The Default Framebuffer may have a depth buffer, and user-defined framebuffers can attach depth formatted images (either depth/stencil or depth-only) to the GL_DEPTH_ATTACHMENT attachment point.

If the current framebuffer has no depth buffer, then the depth test behaves as if it is always disabled.

I hope I'm correct and I wish someone can help to add depth buffer support, it will help a lot.

[poudink]

I see. That would make sense, since my laptop has a shitty integrated amd gpu. Pretty embarassing that it can't even run a mid 2000s video plugin though. I need to see if going through llvmpipe fixes it.
EDIT: Come to think of it, why do you need to go through ANGLE? Doesn't this plugin (or at least the non-mupen version of it) have native D3D support?

[basharast]

EDIT: Come to think of it, why do you need to go through ANGLE? Doesn't this plugin (or at least the non-mupen version of it) have native D3D support?

I have to use it within RetroArch UWP version for universal support (ARM32: W10M - WOA), and there is no way to deal with GL/GLES other than ANGLE.

I believe it will not be very hard to implement the depth buffer if someone already know the structure of Rice and know exactly where the extra code should be added, what I still missing is:

• In which stage in the code I should initial the depth buffer
• From where the depth buffer should get it's own data

sadly I have no Idea how GL/GLES fully work

[poudink]

I mentioned earlier that Glide64 was for some reason also affected by this bug. I tried a few more plugins since then and it seem Arachnoid also has the same issue. In other words, it looks like all HLE plugins besides GlideN64 are affected. LLE plugins are of course unaffected. This was all tested using Mupen64Plus alongside the RMG GUI. Another weird thing to note is that the DaedalusX64 emulator does not have any issues despite its GPU emulation being based on Rice. With it being developed primarily as an emulator for the PSP though, its Linux support is far too barebones to be useful (no audio, no input remapping, no fullscreen, etc.). I wanted to use Mupen64Plus to play some older SM64 romhacks, but unfortunately it seems that all plugins unaffected by this issue are too accurate to properly play them.

[danprice142]

Could this be a alternative? https://www.phoronix.com/scan.php?page=news_item&px=OpenGL-4.2-Mesa-D3D12

[basharast]

I'm not sure about OpenGL since I'm testing on ARM devices (RT, WP, WOA) under OpenGLES
but I'm almost sure that if someone can help to implement the depth buffer info (as depth attachment) the issue will be solved and we will be very thankful for such help.

[basharast]

Closing this and I had to move to GlideN64 (Mupen64Plus-Next).
the issue is not from the core, but from Libretro GL helpers.