search

skmp / reicast-emulator

Reicast was a multiplatform Sega Dreamcast emulator
https://reicast.emudev.org
Other
1.1k stars 343 forks source link

Small sprite glitch in Marvel vs. Capcom 2 #1721

Open Immersion95 opened 4 years ago

Immersion95 commented 4 years ago

Hi,

As suggested from the issue opened on Flycast github, I'm opening the same issue here as it is shared between both emulators (tested with Reicast 6a46275) :

There is a small glitch in this game, it happens during Ryu's "Shinku Hadoken". 1

The glitch is present on all the resolutions.

Thanks for all of your help !

kohi8 commented 4 years ago

A glitch? I don't see a problem that prevents reicast from working as well as it should. All I see is the beam textures not blending correctly which is insignificant. On theory there 3 ways to fix that. Better rendering, better textures and/or bleeding the color of the texture so they can blend together.

skmp commented 4 years ago

I think this is a pixel alignment bug during up-scaling - have you tried running the game in 640x480 resolution?

Pixel alignment issues like these are often bugs in the underlying games, and there's not much we can do - except to hack the games or implement some game specific hackfix.

Eg, one way this happens:

Imagine the game draws a sprite at 0, 31 and another one at 32, 63

When the screen is upscaled by 2x, the numbers become 0, 62 and 64, 126, leaving an unintended 2 pixel gap.

Immersion95 commented 4 years ago

I think this is a pixel alignment bug during up-scaling - have you tried running the game in 640x480 resolution?

Pixel alignment issues like these are often bugs in the underlying games, and there's not much we can do - except to hack the games or implement some game specific hackfix.

Eg, one way this happens:

Imagine the game draws a sprite at 0, 31 and another one at 32, 63

When the screen is upscaled by 2x, the numbers become 0, 62 and 64, 126, leaving an unintended 2 pixel gap.

Hi, no it still does it in every resolution even 640x480

skmp commented 4 years ago

In that case it could be pixel sampling center getting off-by-one error.

ghost commented 4 years ago

Almost same issue in ppsspp 🤔 But it's Street Fighter Alpha MAX 3 https://github.com/hrydgard/ppsspp/issues/8664

Immersion95 commented 4 years ago

In that case it could be pixel sampling center getting off-by-one error.

Thanks for your help, this issue is there on almost all the emulators except for Redream

https://twitter.com/inolen/status/1039226899250262017

ghost commented 4 years ago

@Immersion95 those fixes in 2D graphics games still not implemented in their android version?

RaduNastase commented 4 years ago

The ppsspp one was fixed long ago.

ghost commented 4 years ago

@RaduNastase I don't think so thats why your issue still open in ppsspp github because Mali GPUs still have a graphical glitches 🤷

RaduNastase commented 4 years ago

Oh, you could be right. Mali might still have it.

theurgus commented 4 years ago

@skmp Is some part of the renderer running in the same thread with the sh4? This may be interference from the sh4's rounding mode setting. If it isn't, the problem could be bruteforced by introducing a vertex/edge snapping pass into the TA.

skmp commented 4 years ago

All 3d code runs on its own thread. I think we'll have to do vertex/edge snapping, though this needs to be properly investigated beforehand. I /think/ it is badly-rounded coords from the game (eg, 32-63 instead of 32-63.99 for square quads, that breaks during up-scaling)

theurgus commented 4 years ago

@skmp I'm bothering you again and I'm not very sorry about that - you're the graphics guy anyway :) Now, the rounding mode turned out to be a non-issue - I've tinkered with it to no avail.

Here's a loaded question, though: what does real Dreamcast do when you ask it to render a 10,10 to 10,10 axis-aligned polygon? Does it actually paint a pixel, or does it decide that there's not enough coverage in a 0-by-0 poly to do it? In the former case, this is more of an emulator bug.

I don't have any practical experience in 3d graphics, but I believe a preprocessing hack can be implemented by detecting all axis-aligned polygons by their winding and matching coordinate components in adjacent vertices, then subtracting/adding 0.499(9) to them so the gaps are properly filled. Actually snapping sprites together won't be necessary then.

skmp commented 4 years ago

The Dreamcast's fill convention Is Complicated and Configurable.

The best course of action is to debug with reidbg/refsw and see the actual sprite data, and then cross test on a Dreamcast to make sure things are correct.

I think a spite/pixel alignment pass will fix the issue, thought I haven't tried to implement that.