Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Texture resizes w bilinear filtering #2258

Open
Richard-L opened this issue Jan 11, 2025 · 2 comments
Open

Texture resizes w bilinear filtering #2258

Richard-L opened this issue Jan 11, 2025 · 2 comments
Labels
Enhancement Improvement of an existing feature TR1 TR2

Comments

@Richard-L
Copy link
Collaborator

Richard-L commented Jan 11, 2025

I had brought this up before, so I hope it's okay to post something I observed:

See how Duckstation/TR2X change from nearest neighbour to bilinear filtering (no edge blending).

DS

2025-01-11.23-41-24.mp4

TR2X

2025-01-11.23-42-13.mp4

Sadly TR2X is resizing the textures. TR textures are bad enough, and the super low-poly environments they're on don't help them. Their seamlessness is very hit or miss, to put it lightly. So to further damage this by resizing the textures (when filtered), seems quite costly to me.

If there's anything that can be done to reach Duckstation's no edge blending filtering, I think it would be worthwhile.

@Richard-L Richard-L added the Enhancement Improvement of an existing feature label Jan 11, 2025
@rr-
Copy link
Collaborator

rr- commented Jan 11, 2025

For the record this is OG PC behavior.

Normally we could fix this using GL_CLAMP_TO_EDGE, but the problem is the game uses texture atlases which produces bad artifacts with the bilinear filter on. The solution is to add a fake border around each texture.

Ref:
https://stackoverflow.com/a/35119455
https://gamedev.stackexchange.com/a/61800

This could potentially also help with the anisotropic filtering.

There are two ways I can imagine we could go around this.
The first is to literally offset all texture UVs and add those pixels by hand. It'll require us to support non-256×256 texture pages and has unknown performance hit on level loading.
The other is to use shaders, but this has an unknown performance hit on rendering which is already strained. I think Duckstation implements this here: https://github.com/stenzek/duckstation/blob/ce0689687c58020e9fd45bc3c6b0053b988b63b4/src/core/gpu_shadergen.cpp#L69-L96

CC @lahm86

@lahm86
Copy link
Collaborator

lahm86 commented Jan 12, 2025

I know that TombEditor generates padding around every texture, so whichever pixel is at UV bounds gets repeated. But as you say this means 256x256 tiles become inefficient with lots of dead space.I agree, shifting everything in OG would have a big impact on loading for sure. Texture packing is fast when we're just appending bits and pieces to end tiles, like for injections, but rebuilding the entire set on the fly is another story.
I personally feel it looks fine as is and is in-keeping with OG PC. But appreciate that there is a request for change.

@rr- rr- moved this to Backlog in TRX Dev tracker Jan 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Improvement of an existing feature TR1 TR2
Projects
Status: Backlog
Development

No branches or pull requests

4 participants