Ppsspp: 1.4 Texture filtering is only working half of the time

Created on 31 Mar 2017  路  12Comments  路  Source: hrydgard/ppsspp

Hi! 馃槉
I just got version 1.4 from the ppsspp website, and it's having some weird issues. Even though my settings are the same as the previous version, Menus and textures are looking very pixelated.
Before:
image

Now:
image
I've even tried the new direct3d rendering backend, and it didn't help. The closest I could replicate the old way graphics looked was by using OpenGL and fiddling with settings-- by screwing with the render resolution, the textures would occasionally pop in to being filtered, but if I switched to fullscreen or changed windows it would go back to being pixelated.
The weirdest thing is that in my first screenshot above, the characters are pixelated but the menu has a smooth filter over it. So different textures are being filtered differently? It's bizzare. Sometimes those menus at the top are pixelated as well.

Using Windows 10.
64x bit

No Feedback / Outdated?

Most helpful comment

Something I had in mind which might be difficult to implement is having a sensitivity slider: 0% to 100% where 0% would indicate no consideration on performance and just apply on all frames(dangerous) and 100% would only scale where possible on textures that doesn't change/not very often. Benefit of this would be to let users find their own compromise what works best for them with their hardware.

It would probably require a rewrite to make this working though :/ I don't know if this is something we would want either.

All 12 comments

Some more examples of textures only occasionally being filtered. Right now I'm using Direct3D 11 on the newest dev build (1.4-5).

Below: Healthbar and character icon on the left are nicely filtered, but the rest of the screen is very pixelated and blocky.
image

Related to #1934

This happens when the textures gets changed every? frame so it avoids scaling for performance reasons. You can compile your own build to remove this limitation.

TextureCacheCommon.h
#define TEXCACHE_FRAME_CHANGE_FREQUENT 6
#define TEXCACHE_MAX_TEXELS_SCALED (256*256)

You can tweak those values. If you set FREQUENT to 0 there won't be delays when scaling is applied and MAX_TEXELS_SCALED basically increases the "scope" where scaling occurs; i.e if you change 256*256 to 512*512 or 1024*1024 more textures on the frame will get scaled but this will greatly impact performance depending how often those textures are changed. This is very CPU heavy though.

I don't know if this is the correct way but I can confirm that it works.

@LunaMoo knows a lot more about this than I do, feel free to correct me.

It could of course be that those checks became a little too sensitive in the latest version. We've tweaked them on occasion to fix various issues, it's not easy to get them to work right for all games.

You could make them an config thing or something?

Yeah, well, config things only cause even more testing pains and we already have too many settings..

Something I had in mind which might be difficult to implement is having a sensitivity slider: 0% to 100% where 0% would indicate no consideration on performance and just apply on all frames(dangerous) and 100% would only scale where possible on textures that doesn't change/not very often. Benefit of this would be to let users find their own compromise what works best for them with their hardware.

It would probably require a rewrite to make this working though :/ I don't know if this is something we would want either.

This happens when the textures gets changed every? frame so it avoids scaling for performance reasons. You can compile your own build to remove this limitation.

How do I compile my own build? Like I know you gave a few lines of code but where do I put that? Or should I just revert to 1.3?

https://github.com/hrydgard/ppsspp/wiki/Build-instructions

If you're not up for that, feel free to stick around on 1.3 until we improve this.

@winterdrake you change it here: http://i.imgur.com/xNxQTuZ.png
But first you must do the necessary steps to be able to view the code, change it and compile it.

Additional help(although outdated) can be found at http://forums.ppsspp.org/showthread.php?tid=5231 to get started. When you get to step 6 though, add --recursive at the end so it becomes:
"git submodule update --init --recursive".
Take the information on that forum thread with a grain of salt since things have changed but it does contain information on how to clone the repository, which isn't explicitly explained on the wiki page.

Thank you both!! Glad to know you're gonna try and improve it.

Ultimately, the biggest problem is when a 512x512 texture is scaled once every frame, causing problems like #9125. When we introduced texels per frame, I hoped we could eliminate the frequent check, but unfortunately that issue proved we can't.

With that said, maybe we can now reduce the frequent check only to textures larger than TEXCACHE_MAX_TEXELS_SCALED, or something. But perhaps this game is just animating a large background texture?

It may even be possible to reduce the number of texels we're scaling, which could lead to some benefit. If we only scale the top 272 of a video, it reduces the work by ~45%. That might allow us to make the defaults allow for more frequent scaling.

What's the lowest value for TEXCACHE_FRAME_CHANGE_FREQUENT where the scaling is still visible? If it's set to 1, does it still not work? This is how many frames between a change are allowed to scale the texture.

-[Unknown]

Has this improved in 1.5.4 or the latest git builds?

-[Unknown]

Was this page helpful?
0 / 5 - 0 ratings