PCSX2 / pcsx2

PCSX2 - The Playstation 2 Emulator
https://pcsx2.net
GNU General Public License v3.0
11.49k stars 1.6k forks source link

Soulcalibur III [NTSC-U] - inverted colours during transitions #1931

Closed trostboot closed 3 years ago

trostboot commented 7 years ago

PCSX2 version: 1.5.0-dev-1976

PCSX2 options: defaults

Plugins used: GS: GSdx32-AVX2.dll [GSdx 20170401111625 (MSVC 19.00 AVX2/AVX2) 1.1.0] PAD: padPokopom.dll [Pokopom XInput Pad Plugin 2.1.0] SPU2: SPU2-X.dll [SPU2-X 20170401111625 2.0.0]

Description of the issue: For a brief time during transition to the loading screen after character select, colours will be inverted in the bottom half of the screen. Present across all renderers, hardware and software. (actually they're not exactly inverted on closer look, but you get the idea)

gsdx_20170504225046 GSdump: gsdx_20170504230020.zip

How to reproduce the issue: Go through character select in any mode.

Last known version to work: Tested 1.0.0, present there as well.

PC specifications: i5-4690k, R9 270X, 16GB RAM, Win10 Pro 64bit 14393

MrCK1 commented 6 years ago

Issue is still present, it appears at 2082 in the dump.

ghost commented 5 years ago

Is it still present? Gt4 used to do a similar problem and it no longer have inverted colors.

trostboot commented 5 years ago

Had a quick look at OGL SW and HW using latest git, still there. More pronounced on the HW renderer.

ghost commented 5 years ago

So this happen with booth the software and hardware render. Did you try the Xgkick hack or various clamping/rounding values for the EE/IOP and the VUs?

trostboot commented 5 years ago

So this happen with booth the software and hardware render.

As was stated in the original issue report.

That aside, the only option that changes anything is EE interpreter, which appears to fix it. So this looks like a bug in the EE recompiler. The image still appears a bit light at the end of the transition, but off the top of my head I don't know whether that's normal behaviour or not. I can check on real hardware tomorrow if need be, but that would be an even more minor issue..

MrCK1 commented 3 years ago

@trostboot are you able to retest this on the latest dev build with all the EE rounding/clamping modes?

refractionpcsx2 commented 3 years ago

I tried the EU version on latest master and it doesn't seem to do it.

trostboot commented 3 years ago

Same for the US version (SLUS-21216). There's some run-to-run variation that may make it look like some modes improve it slightly, but it averages out to the same across multiple runs with the same settings. Just something to be aware of if you test it yourself.

refractionpcsx2 commented 3 years ago

So are you saying it still happens but it's apparently random if it does? Just so we're clear

trostboot commented 3 years ago

It always happens, but the duration can change from run to run. It may flicker between correct and wrong colours quickly, or it might just be one long continuous display of wrong colours, or just a short, almost imperceptible one.

I went back and looked at 1.5.0-dev-3072 (the oldest build on the bot currently) and the behaviour is the same there, so nothing has changed in that regard.

refractionpcsx2 commented 3 years ago

Okay so what mode do you notice it most on? and which character do you select? because I'm not seeing it, even trying the US version.

trostboot commented 3 years ago

Ohhh, sorry. I interpreted your "doesn't seem to do it" as "didn't fix it".

I've narrowed it down to only occurring in progressive scan mode (the usual Triangle + X on boot). I checked regular interlace mode on a hunch after your comment, and you're right, it doesn't appear to be happening there. Character and game mode doesn't seem to matter.

refractionpcsx2 commented 3 years ago

I've narrowed it down to only occurring in progressive scan mode

Okay that information would have been would have been useful 3 years ago :P

Edit: Okay NOW I can reproduce it

trostboot commented 3 years ago

Fair, it just never occurred to me to try that. Booting it up in progressive scan is just a reflex, and no one mentioned it not happening to them before.

refractionpcsx2 commented 3 years ago

Okay, can you try setting your EE Cycle Rate under speedhacks to -1 on latest master? I think that fixes it. If it's a timing issue like this, it might be very difficult to fix it (if at all)

trostboot commented 3 years ago

Yeah, can confirm. And conversely, raising the cycle rate makes it worse (as in, completely consistently wrong, rather than intermittently).

refractionpcsx2 commented 3 years ago

Yes, I think this is just a timing problem due to the recompilers running in blocks instead of accurately, which can cause sync problems occasionally, I'm afraid this might be the only fix.

trostboot commented 3 years ago

It is what it is. I suppose a long-term goal of more accurate core timing (even at the expense of performance) isn't something anyone has shown any interest in trying to tackle.

Apples and oranges (if that), but fwiw, it's displayed correctly on a PS3 running under ps2_netemu. May just be a lucky accident, of course. Maybe their timings are off by default in the right way for this particular issue. ;)

refractionpcsx2 commented 3 years ago

That is true, however getting EE Timing absolutely right is a complete nightmare, especially when recompilers are thrown in to the mix, if we went for absolute perfect timing, the emulator would probably run at 20fps in all games (and I'm not even kidding). I suspect the PS3 is just luck yes

ghost commented 3 years ago

The PS3 is luck most of the time yes but I also suspect they handle the timing in some games manually else, by slowing down the ee or making the VUs faster/slower depending the game.

ghost commented 3 years ago

And btw, does ee timing hack produce anything?

refractionpcsx2 commented 3 years ago

hmm yeah EE Timing hack seems to work, that might be a better solution as we can put that on automatically and you don't have to mess with speedhacks

@trostboot can you confirm?

trostboot commented 3 years ago

The PS3 is luck most of the time yes but I also suspect they handle the timing in some games manually else

Not in this case, it's not an officially supported classics title.

Re: EE timing hack, yes, that appears to work. Is that likely to break anything that would need further testing?

refractionpcsx2 commented 3 years ago

The EE Timing hack is "kind of" more acccurate, but not at the same time, it's a strange one to explain :P But I'll add it to this version of Soul Calibur, and that will solve it going forward.

trostboot commented 3 years ago

@refractionpcsx2 Does the EU version not have the progressive scan option (I don't have it myself)?

refractionpcsx2 commented 3 years ago

Nope, we didn't really have it as it. I believe this is because it's a lower resolution than PAL could actually output.

I wish we did have it though, I'd sacrifice a bit of resolution for no interlacing!

trostboot commented 3 years ago

Actually there's a number of PAL releases that do have 480p support (which makes sense since there's already releases that also support interlaced 60hz modes instead), but you're right, Soulcalibur 3 isn't one of them apparently. 2 is, though. Go figure.

That leaves the Japanese release. I would guess it's in there, but haven't found anything definitive.

refractionpcsx2 commented 3 years ago

Yeah, but to be honest I'd rather adjust it as we come across the problem instead of blindly adding game fixes when they might not be needed.

trostboot commented 3 years ago

Agreed. I can confirm that both the Japanese release (SLPS-25577) as well as the Korean release (SCKA-20059) offer progressive scan modes, and have the same issue and fix.

refractionpcsx2 commented 3 years ago

screw it, I'll just do all the NTSC versions.