Regression: Capcom games suffering from lines on right part of screen

[prafullpcsx2]

Describe the Bug

Although this bug only happens while upscaling but since this is a regression I am posting this bug report.

Capcom games like Onimusha 3, Onimusha 4, Devil may Cry 3 and may be others show graphical artifacts in shape of lines on right side of the screen. These vary from game to game but location is almost same. My testing suggests that this bug started happening after #5387 was merged.

Using round sprite Full reduces the problem but doesn't fix it completely.

Reproduction Steps

Run these games and they suffer from the mentioned bug during some cutscenes/ingame. I have attached multiframe gsdumps so testing becomes easier.

Expected Behavior

Game should run without any graphical issues.

PCSX2 Revision

All versions after v1.7.2300 suffer from this problem

Operating System

Windows 10 (64bit)

If Linux - Specify Distro

No response

CPU

i3-9100f

GPU

750Ti

GS Settings

Default settings with or without upscaling hacks.

Emulation Settings

No response

GS Window Screenshots

No response

Logs & Dumps

http://filedropper.com/UvZnto1X

[Dreadmoth]

Shadow of Rome is also affected by this issue:

Shadow_of_Rome_right_edge_line.zip

#5853 increases the severity of the issue - in addition to the line on the right, lines also appear at the bottom of the screen. Faint and blurry at 2/3x native, opaque and well-defined at 4x native and higher.

[TellowKrinkle]

Okay I looked at Shadow of Rome
Here's a draw on a build not affected by this problem:

Game renders a sprite to a 128x56 target from (28664, 30972) to (30712, 31868) with XYOFFSET (28672, 30976). Convert that to pixel coordinates and you get (-0.5, -0.25) to (127.5, 55.75). This means that it never touches the rightmost 0.5 of a pixel and the bottommost 0.25 of a pixel, which become whole pixels when upscaling.

So the game has always been broken, but our broken samplers were covering this up by trimming the right and bottom edges off textures.

IMO the proper solution to this is upscaling hacks that affect where the game draws (e.g. round sprite), rather than how we sample textures, but curious of what others think @refractionpcsx2

[refractionpcsx2]

You might be right in that case, it certainly sounds like an upscaling bother. It does bug me how we upscale even the fragment part of the integer where in reality it would get rounded/floored beforehand then the pixel coord is decided, rather than a "nearest" kind of thing, since that would screw our upscaling, but I honestly don't have a real solution for what pixels we draw, so upscaling hacks might be the way forward for that, at least for now.

Maybe @RedDevilus or somebody can play with a concoction of hacks to see if something resolves/reduces it for now.

What's the situation with the capcom games?

[prafullpcsx2]

After keenly observing games I noticed there are some other regressions caused by 5387 in these games.

That black shadow like box in the middle isn't supposed to be there

Attaching another gsdump for the same

gs_20220420153427_Onimusha 3 - Demon Siege _NTSC-U__SLUS-20694.zip

[TellowKrinkle]

Can you test that on #6021? I can't repro with it, and I can't play the GSdump without it in the Metal renderer.

[ghost]

Tested. Both Lines and Shadow issue on upscale are still there.

[prafullpcsx2]

Can you test that on #6021? I can't repro with it, and I can't play the GSdump without it in the Metal renderer.

All bugs still present on #6021

[refractionpcsx2]

This is caused by this code right here

        if (m_context->CLAMP.WMS == CLAMP_REGION_CLAMP && MIP_CLAMP.MINU == 0 && MIP_CLAMP.MAXU == tw - 1)
            m_context->CLAMP.WMS = CLAMP_CLAMP;
        else if (m_context->CLAMP.WMS == CLAMP_REGION_REPEAT && MIP_CLAMP.MINU == tw - 1 && MIP_CLAMP.MAXU == 0)
            m_context->CLAMP.WMS = CLAMP_REPEAT;
        else if ((m_context->CLAMP.WMS & 2) && !(tmm.uses_boundary & TextureMinMaxResult::USES_BOUNDARY_U))
            m_context->CLAMP.WMS = CLAMP_CLAMP;
        if (m_context->CLAMP.WMT == CLAMP_REGION_CLAMP && MIP_CLAMP.MINV == 0 && MIP_CLAMP.MAXV == th - 1)
            m_context->CLAMP.WMT = CLAMP_CLAMP;
        else if (m_context->CLAMP.WMT == CLAMP_REGION_REPEAT && MIP_CLAMP.MINV == th - 1 && MIP_CLAMP.MAXV == 0)
            m_context->CLAMP.WMT = CLAMP_REPEAT;
        else if ((m_context->CLAMP.WMT & 2) && !(tmm.uses_boundary & TextureMinMaxResult::USES_BOUNDARY_V))
            m_context->CLAMP.WMT = CLAMP_CLAMP;

Namely the first WMS and WMT checks to convert it to CLAMP_CLAMP, get rid of those (or add a check to see if it's m_vt.IsLinear())and you can upscale with Special Texture and you get no leakage or anything, works great.

I don't think this is directly the bug, because it should work in theory if the MIN/MAX match 0-tw, or whatever, which in this case it does (ofc, I mean it triggers it..), but something down the chain is breaking it, or the bilinear sampling is messing up, I don't know which it is, could be indicative of another bug with normal CLAMP mode.

This also causes problems in GT4 making the sprites for the cars disappear in the score board along the bottom of the picture below, same thing fixes it. (This however requires you to reboot the game to change the behaviour, so no GS dump)

[lightningterror]

Closing as workaround possible.
702aefa