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

Metal Slug XX - texture issue at combat school #15755

Open
5 tasks done
ghost opened this issue Jul 30, 2022 · 8 comments
Open
5 tasks done

Metal Slug XX - texture issue at combat school #15755

ghost opened this issue Jul 30, 2022 · 8 comments
Labels
GE emulation Backend-independent GPU issues
Milestone

Comments

@ghost
Copy link

ghost commented Jul 30, 2022

Game or games this happens in

ULUS10495 Metal Slug XX v 1.01

What area of the game

When you are going to the Combat School option in the game you could see that when the character sprite mouth moves.

What happens

There is what some people call "misaligned texture" around the mouth area.
You can see it here:
unknown

What should happen

There should be no issue with the graphics there.
Note: You can still notice this happens even without upscaling its just less obvious.
Also , this happens on both Vulkan and OpenGL.

GE frame capture

ULUS10495.zip

Platform

Linux / BSD

Mobile phone model or graphics card

AMD Radeon 530/Intel UHD 620

PPSSPP version affected

1.13.1

Last working version

No response

Graphics backend (3D API)

Vulkan

Checklist

  • Test in the latest git build in case it's already fixed.
  • Search for other reports of the same issue.
  • Try resetting settings or older versions and include if the issue is related.
  • Try changing graphics settings to determine if one causes the glitch (especially speed hacks or enhancements/replacements.)
  • Include logs or screenshots of issue.
@ghost
Copy link
Author

ghost commented Jul 30, 2022

Curiously the game shows the character properly wiith upscaling on MelonDS (which is notorious for having many misaligned texture issues on other games).
unknown

In addition, this issue still happens on PPSSPP even with software renderer enabled:
image

@hrydgard hrydgard added the GE emulation Backend-independent GPU issues label Jul 30, 2022
@hrydgard hrydgard added this to the Future-Prio milestone Jul 30, 2022
@unknownbrackets
Copy link
Collaborator

Just to confirm, a PSP does render this frame dump properly:
#15755_ULUS10495_metal_slug_face

Vulkan gets it right too, but only at 1x. I explain here why it's problematic to handle these cases at higher resolutions: https://forums.ppsspp.org/showthread.php?tid=13556
For this game, it might be better to just use an upscaling shader instead of a higher render resolution.

Anyway, in software it draws the face like this:
Texture with mouth and chin next to partial render

It's a triangle strip rectangle, in transform (3D) mode, and the coordinates are not very accurate:

X Y Z U V
300.687500 87.000000 10000.000000 151.978500 88.387581
332.625000 87.000000 10000.000000 183.454727 88.387581
300.687500 118.937500 10000.000000 151.978500 119.984131
332.625000 118.937500 10000.000000 183.454727 119.984131

If I disable Rasterizer::DetectRectangleFromStrip(), it draws correctly, so this must be some issue with the math specifically in DrawRectangle when S/T aren't even.

As I described in the posted link, this is a case of "bad math." Software is a bug, but hardware at 2x is just doubling all the coordinates. Snapping to pixels will make 3D graphics look worse at higher render resolutions.

Screen positions are 31.9375x31.9375 from a texture that's 31.476227x31.59655. That should end up close enough (it seems) at 1x, but the higher the resolution, the more those diverge.

-[Unknown]

@ghost
Copy link
Author

ghost commented Oct 1, 2022

Vulkan gets it right too, but only at 1x

ULUS10495_00002

On 1x there is a rectangle below her mouth for some reason...
I tried to capture it but it's not that easy as well(you can notice it if you squint hard enough) , it only happens when her mouth flaps move though.
This is on the latest PPSSPP I just recently updated.

@unknownbrackets
Copy link
Collaborator

To me, that just looks slightly off-color, I wonder if it's a slightly different bitdepth and dither/etc. solves it on actual hardware. Does that happen in the software renderer?

-[Unknown]

@ghost
Copy link
Author

ghost commented Oct 1, 2022

To me, that just looks slightly off-color, I wonder if it's a slightly different bitdepth and dither/etc. solves it on actual hardware. Does that happen in the software renderer?

-[Unknown]

No the coloring seems fine there.
Now I found another issue with one of the logos in the intro.
There is an additional black line you can notice at the right corner next to the logo.
image

Also uploaded a frame capture here as well:
ULUS10495.zip

unknownbrackets added a commit to unknownbrackets/ppsspp that referenced this issue Oct 17, 2022
If the start coordinate was something like 51.75, we were incorrectly
drawing to 51.  This can be seen in the Metal Slug intro (hrydgard#15755.)
@unknownbrackets
Copy link
Collaborator

I believe #16241 fixes all the software renderer issues noted here.

Looking more closely at Vulkan, you're right that it's rendering this wrong - even with anisotropic set to off. It seems like it ends up sampling or drawing slightly outside where it should. This might still be tricky to fix due to the math concerns I mentioned, but I was hoping we wouldn't see issues of this at 1x...

-[Unknown]

@LunaMoo
Copy link
Collaborator

LunaMoo commented Dec 30, 2023

Didn't tested this before, but currently it seems to render fine with x1 render res at least on vulkan and using the 2 dumps provided, it also works in software renderer, it can also be completely hidden by texture scaling, but this might depend on the resolution used, on my 4k TV only x6 texture scaling completely hidden it and we don't have that in official releases.

x1 render res vulkan
ULUS10495_00002

software renderer
ULUS10495_00001

x6 xBRZ texture scaling(probably less is enough for smaller res)
ULUS10495_00000

Texture replacement would probably be the best way to deal with(I mean for the end user, not a weird built-in workaround). At least assuming the actual game isn't running on some emulator and replacement is usable.

@LunaMoo
Copy link
Collaborator

LunaMoo commented Dec 31, 2023

Loked at the actual game now and found some BS happening here:

  • we don't have any problem with emulation in here now, imo it looks as it should given what it has to work with at x1 render res,
  • some original textures of this character face have missmatched colors in PSP version, this is probably caused by using incorrect resizing software that messed up color palete while porting to PSP and this is what causes noticeable seams with some expressions in x1 render res.
    Clipboard02
    an example of color difference on part of the cloth between different textures(taken from original unmodified textures of different face expressions)

The only way to "fix" it is to mod those textures correcting colors in them(Edit: althrough LCD persistence shader can minimize it to the point of not being seen, potentially why this was good enough for release).

To work around the seams above x1 render res the usual work:

  • xbrz texture scaling or replacement above render res,
  • enforcing nearest texture filter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GE emulation Backend-independent GPU issues
Projects
None yet
Development

No branches or pull requests

3 participants