search

gonetz / GLideN64

A new generation, open-source graphics plugin for N64 emulators.
Other
762 stars 175 forks source link

Texture sampling does not correctly wrap to the start of tmem when tmem address overflows #2683

Closed Mr-Wiseguy closed 2 years ago

Mr-Wiseguy commented 2 years ago

By setting tile mask to 0 and manipulating tile size high and low values, you can cause the tmem address to wrap back to zero during texture sampling. This does not seem to work correctly on GLideN64, which instead reads what appears to be random data outside of the emulated tmem.

Console output: image

GLideN64 output (the pink and white line under the orange rectangle are the incorrect pixels): image

Tested with GLideN64 public release 3.0, 4.0 and commit: https://github.com/gonetz/GLideN64/commit/8343fd0

Xii-Nyth commented 2 years ago

great job figuring this out!

gonetz commented 2 years ago

Actually GLideN64 wraps TMEM address. May be it does not work for some texture format. Which texture format is used here? Where to get that rom to test?

Mr-Wiseguy commented 2 years ago

The format is RGBA16. There are two 32x32 RGBA16 textures in TMEM, one at address 0 and one at address 2048. In that screenshot, I'm only drawing the first texture but I've adjusted the clamping parameters so that it reads from the second texture's TMEM while drawing it.

The rom is one I wrote myself for testing some export tooling I was working on. I've uploaded it here: https://drive.google.com/file/d/1HYq6JMwEwyWBWh4Kzcp3-ySdNsXwWSZJ/view?usp=sharing Simply configure the texture sampling parameters to match the ones in the screenshot to reproduce the issue.

Jj0YzL5nvJ commented 2 years ago

I can't replicate it, the result with angrylion-plus seems more interesting. https://imgur.com/a/OCVA8FU

Save state: tex_sampling_demo.zip

Mr-Wiseguy commented 2 years ago

It may be only be an issue with the Zilmar-spec build of GLideN64, since I used PJ64 in my testing.

Jj0YzL5nvJ commented 2 years ago

It may be only be an issue with the Zilmar-spec build of GLideN64, since I used PJ64 in my testing.

Project64 freezes when loading a save state for your test ROM... Try the latest "nightly build".

Mr-Wiseguy commented 2 years ago

Trying a nightly build of GLideN64 fixed the issue. It seems it was fixed somewhere between 8343fd0 and 47b0de1. If I were to hazard a guess, I'd say 8a0db39812a81daeaa6dc490c13ca211db247fa7 fixed it. Feel free to close this issue.

gonetz commented 2 years ago

Fixed, supposedly by https://github.com/gonetz/GLideN64/commit/8a0db39812a81daeaa6dc490c13ca211db247fa7 Closed.