Regression in Zelda MM after #2537

[gonetz]

Before #2537 SD

HD

After SD

HD

@standard-two-simplex please take a look. I reverted 73b2d0060bd.

[gonetz]

@standard-two-simplex it seems that with new lod calculation methods low-res levels selected too early. master: branch: Parallel RDP - something in between the first two:

[fzurita]

Very odd issue with LOD disabled in settings: https://drive.google.com/file/d/1XhzDhuTuARfguY9N0uObOQNk6GrXztWT/view?usp=drivesdk

[gonetz]

False alarm - Parallel RDP gives the same result as the branch, when it works without upscale or when NativeTexLOD is enabled with upscale: We are good :)

[gonetz]

Very odd issue with LOD disabled in settings: https://drive.google.com/file/d/1XhzDhuTuARfguY9N0uObOQNk6GrXztWT/view?usp=drivesdk

Is it master?

[fzurita]

mip_map_lod_refactor branch, but I'm not at the latest commit.

It doesn't happen in master.

[gonetz]

Checked mip_map_lod_refactor branch with LOD disabled, this place in GE works ok on my PC.

[bslenul]

Sorry if this is a dumb question, but comparing your mip_map_load_refactor branch / ParaLLEl screens above, is it normal that the textures on the side seem "unfiltered"?:

edit: And some textures in Perfect Dark still feel "wrong":

GlideN64 (6274baa)	ParaLLEl-RDP

The floor looks very weird (and you can see "unfiltered" textures on the wall in the background as well, but again idk if that's normal or not). Mupen state: Perfect Dark (U) (V1.0) [!].zip

[gonetz]

The floor looks very weird

Very weird? The floor looks a bit different because you run GLideN64 with standard bilinear filtering. Select N64 3-point filtering and it will be the same as ParaLLEl-RDP, which uses only that filtering method. Screen shot:

It is very close to ParaLLEl-RDP. The main difference is that ParaLLEl-RDP picture is blurred on the distance. It can be result of RDP/VI post-filters, which are not emulated by GLideN64. It also can be the reason why GE textures look more blurred with ParaLLEl-RDP. GLideN64 filters mip-map textures. I can disable the filter to show you how unfiltered textures look like.

[gonetz]

mip_map_lod_refactor branch, but I'm not at the latest commit.

It doesn't happen in master.

Please check that there are no shader compilation errors. PC version works fine with LOD disabled.

[fzurita]

Ok, I updated to the latest commit in the branch and the problem is gone.

[fzurita]

It's not looking very good in GLES 2.0:

As I turn the camera around, it alternates between the two errors.

[fzurita]

It's probably better to drop GLES 2.0 support, it's becoming too difficult to support and devices are just too slow at this point with all the accuracy updates.

[bslenul]

It is very close to ParaLLEl-RDP. The main difference is that ParaLLEl-RDP picture is blurred on the distance. It can be result of RDP/VI post-filters, which are not emulated by GLideN64. It also can be the reason why GE textures look more blurred with ParaLLEl-RDP.

Ah thanks for the little explanation, I think I understand a bit better why it looks different now.

GLideN64 filters mip-map textures. I can disable the filter to show you how unfiltered textures look like.

Yeah sorry, I said "unfiltered" in quotes because I wasn't sure how to say it in other terms, but yeah I imagine it wouldn't look like that if it was truly unfiltered 😅

[gonetz]

It's not looking very good in GLES 2.0:

I could make a mistake in implementation.

It's probably better to drop GLES 2.0 support

I planned to do it after new Public Release.

[ghost]

It's not looking very good in GLES 2.0:

It may be because of this. https://github.com/gonetz/GLideN64/commit/6274baaaece1bd0b4501488d4a0a0c9918bcba94#r55602592

[gonetz]

It may be because of this. 6274baa#r55602592

Yes, it is one of the issues with GLES 2.0 code. I rewrote it: 0a417ce863b I'm not sure how fast GLES 2.0 devices can run it, but at least it should work. I tested it on my PC (just replaced texture2D with texture)

[ghost]

An explanation of the algorithm would be really great. Could you add it to Wiki page?

I forgot to mention, but this was done some days ago.

https://github.com/gonetz/GLideN64/wiki/Level-of-detail-emulation:-lod-per-pixel-calculation,-tile-selection-and-third-axis-interpolation-factor-computation.

[fzurita]

I tried the latest version and there was no improvement in one of my GLES 2.0 devices. It still looks the same as the pictures above.

MAX TEXTURE SIZE=4096 on this device.

[gonetz]

I forgot to mention, but this was done some days ago.

Very good article, thanks!

[gonetz]

I tried the latest version and there was no improvement in one of my GLES 2.0 devices. It still looks the same as the pictures above.

MAX TEXTURE SIZE=4096 on this device.

It's strange. Max texture size is unimportant now, since I load mipmap texture atlas as 256xN texture, where N is number of texels / 256. Could you

• check, that there are no shader compilation issues
• dump a shader with mipmap function?

Probably I forgot to enable smth for GLES2 case.

[fzurita]

Ok, I'm actually getting shader compilation errors in GLES 3.0 and other errors in GLES 2.0. I'll go ahead and fix them and make a pull request to the branch.

[fzurita]

I submitted this pull request to fix GLES 2.0: https://github.com/gonetz/GLideN64/pull/2568

Unfortunately, GLES 2.0 lost A LOT of performance, I wouldn't consider it playable, at least with goldeneye.

[fzurita]

I see that it was merged to master, RIP GLES 2.0 performance, lol.

[fzurita]

I have an experimental branch that goes back to the old way of doing things before the texture engine change while keeping all other recent changes here:

https://github.com/fzurita/GLideN64/tree/fast

I will probably include the master branch as well as this "fast" branch in mupen64plus-ae and allow users to use the old code as an option for users that have slower devices.

I did the above by doing a git rebase, removing the commits, and resolving conflicts.

Here is the same as above but as one commit in the end that reverts everything: https://github.com/fzurita/GLideN64/tree/fast2

If we wanted to add some code that makes the texture engine optional, the above could be used as a base.

[dankcushions]

thanks @fzurita ! would it be ok to use your 'fast' branch in RetroPie for GLES2 devices? i don't have such a device to check but the Pis could barely run it before the changes 😆

i don't want to feel like you have the burden of supporting a branch so we could move back to master/a previous commit at any point if it becomes a hassle.

[fzurita]

Feel free to use it, although, I would use the fast2 branch, it would be easier to support.

Ideally, this should be a configuration parameter.

@gonetz with the fast2 branch I have, it becomes really easy to see what it would take to do to make all the changes that hurt slower devices configurable. Would you take a pull request that makes any code paths that use texelFetch configurable?

[gonetz]

@gonetz with the fast2 branch I have, it becomes really easy to see what it would take to do to make all the changes that hurt slower devices configurable. Would you take a pull request that makes any code paths that use texelFetch configurable?

Actually, I'm thinking about it since the moment the texture engine was merged. Unfortunately, the changes are quite deep. Texturing code already makes me dizzy. If we just add "if (fast_code) piece_of_fast_code else piece_of_precise_code)" everywhere, it will make the code even more unreadable. May be we can add an interface class, say TexturingGenie :), which will provide unforms and shaders for texturing? And make several (at least two) implementations of this class. Or use other trick to separate the code.

[fzurita]

How about: glsl_CombinerProgramBuilderFast/glsl_CombinerProgramUniformFactoryFast vs glsl_CombinerProgramBuilderAccurate/glsl_CombinerProgramUniformFactoryAccurate. I could use some tricks to load the correct version of the individual classes in that file, probably put them each in a namespace and implement some sort of interface class.

[fzurita]

@gonetz I did as suggested here: https://github.com/gonetz/GLideN64/pull/2593

Let me know what you think.

[gonetz]

The regression is fixed.