Open gregory38 opened 8 years ago
having a scan through my games to see if i can find any others that do it.
Destroy All Humans - it's not overly noticable (due to the shadow mess on the screen)but its there. Hitman Blood Money - Seems to have 2 levels of it? one shows more than the other (wrong colour though)
Edit: Totally O/T but you've nearly fixed Driver 3's graphics! The text is still a bit broken but it's readable and most of the texture flicker is gone, you just get the odd little bit now.
I have a dump of this game, but I don't see it. Maybe not the good scene. However there are various postprocessing effect.
ill try and get another one if you'd like, it even does it on the menu, but im not totally sure it's right.
I'm updating that post as i find games btw
Ok. So far I have enough gs dump to implement somethings
Stuntman also crashes with a RAM spike with OpenGL(this happens more often now than on 1.4.0).
Ok. I'm nearly sure it is a variation of a similar effect. Currently my detection is based on FrameBuffer address == Texture address. However Prince Of Persia. Copy the Framebuffer to another place. So my detection is dull. (and move is badly emulated in texture cache). However detection work nicely for MGS and killzone.
That's progress :)
OK finished going through my DVD ISO's, there wasn't really many that weren't already mentioned that I could find. There might be more but I'm totally not going through all my discs ;)
Ok. Let's me first try to correct MGS/KillZone. For PoP, I need to find a way to detect the mess. Or maybe we could rely on crc/option.
For PoP, I need to find a way to detect the mess. Or maybe we could rely on crc/option.
That all depends how often that effect is used and what drain on performance it is. If this is the only game to use it, or there is a huge performance drop, then yeh, option it (so people have an option)
Without CRC ;)
The trick is to properly detect the effect. My current implementation replace current draw call by an alternate draw call. Option or CRC will help to avoid side effect. Anyway, I need to find a way to correct the move first.
@ssakash you need to check several open issues.
At all I pushed my implementation on master. Time to give it a shot.
Good job! ill give it a go :)
Rachet & Clank - Don't think it ever had this issue, that has mipmapping problems. MGS 3 - Yay looks much better now! :) Prince of Persia - Screen is completely blue GT4 - Still has the weird colours when transitioning between scenes (it was blue this time) Urban Chaos - screen is completely pink tinted but now the box in the top left IS the correct colours and no longer wrong, nor is it sliced! Killzone - has a half screen cut off now. bottom half being darker but you can see the game. Destroy All Humans - Still has the box in the top left, it looks like it is used to fade the background when you have a menu open (this is probably why you never saw it) Hitman Blood Money - Seems to be fixed now! :)
3/6(or 8 if you count possible different issues) fixed! :) i might give you 3.5, half a mark for Prince of Persia ;)
Killzone already had the half screen issue. The infrared view is now fixed.
Splinter Cell: Pandora Tomorrow infrared view is also fixed.
Try this hack for killzone UserHacks_ColorDepthClearOverlap = 1
If it doesn't work, I think I know the issue. Various game suffers of this half-screen issue.
It doesn't work(yes, userhacks was on).
Thanks for the test, so it is the 2nd bug ;)
GT seem to be a different issue. Urban Chaos effect is halfly detected. It also moves the RT as pop (but differently).
Can confirm (checked with depth enabled on OGL as well, just in case) that the colourdepthclear line doesn't affect Killzone, so yeh, its the half screen issue, which is another one of those affects a ton of games bugs :P
Oh nice, PoP is pink now. You can chose the rendering for boys or girls ;)
Oh nice, PoP is pink now. You can chose the rendering for boys or girls ;)
lol xD
Hum, actually I think it is working for PoP but it fails to handle the old texture shuffle. It is implemented very strangely (it is maybe not a texture shuffle).
I'm sure you'll sus it :)
My god, I don't know what they smoke but it must be very strong!
Here are the step
....
blinks...... blinks again...... tries rubbing eyes...... What the hell??? That seems an awfully long way around doing things.
Yes it is a nightmare. I don't count the number of texture conversion and the number of draw call to emulate this mess... It is due to the fixed behavior of GS. It will be free on a modern GPU (a single draw call no conversion...) I need to create a new shader to move the blue channel to the alpha channel (for the texture shuffle). I hope will be enough.
Fingers crossed.
I feel almost like we should hle this crap and get a fingerprint of the setup of the gs for each type of draw and do it all the pc way and just copy the result back instead of having to do what the gs would normally do.
Devil May Cry still has the box in the top left corner as well
@MrCK1 does the game require lots of memory (set scaling to 4x-6x).
@refractionpcsx2 well it is more less what I'm trying to do. I don't emulate texture conversion, and I skip various draw call. But 1 PC draw call can do N GS draw calls (N could be bigger than 300), even a basic effect requires 2/3 GS draw calls. So actually my texture shuffling is partially working so it is maybe not the issue. And finally understood what the game is trying to do with all this mess. It is only a color (gamma?) correction. So rendering is basically
out.r = color_table_r(out.r);
out.g = color_table_g(out.g);
out.b = color_table_b(out.b);
Because GS can access a single channel, the game uses various trick to move thing around. So the first color channel trick will handle the Red. The "old" texture shuffle will do the Green. And the last color channel trick will manage the Blue.
Awesome :) I'm expecting the next fix to sort it completely then! :)
Let's hope so.
So, issue is that I'm dumb. Current implement expects that texture and RT are the same, so I sampled the RT directly. New code can detect case where texture and RT are different. But RT was still sampled...
Here the status of PoP now (4x by the way, without crash)
Edit: however require preload hack.
That looks much better :)
TBH I leave the preload hack on, now it doesn't crash :P Doesn't seem to do any harm.
TBH, preload is a pseudo hack. It feels more correct to enable it (however it could impact the perf). But FlatOut told me that he got some glitches on FMV.
UrbanChaos is still wrong but better (on 4 frames we now skip 1112 draw calls....)
nice! That's some impressive work :) optimising ftw! Maybe one day we will be as fast as Dolphin lol
@MrCK1 does the game(Devil May Cry) require lots of memory (set scaling to 4x-6x).
I've just tried it and it does not. I can run it on 6x native OpenGL, hw depth, accurate date, Blending on Ultra at full speed. :P It still has the small duplicate frame in the top left though.
Do you have this duplicate frame on SW ?
I opened a PR #1322 with the new code. Hope it won't generate any regression. I'm currently looking urban chaos now but I'm afraid there is another effects...
Destroy All Humans - Background fading effect thing is fixed and has the right pattern on it, good job! Urban Chaos - Yes much much better, still has a horrible "fog" effect MGS3 - Ingame still looks fine, Codec is now a cartoony grey colour, which I think it is supposed to be going from google images! I don't know about infrared, haven't got that far.
OoO there is bad interaction with my depth implementation. The game read back the depth buffer 16 bits as an 8 bits index. I expected no sane dev would do that because everything will be scrambled. It seem someone manage to find an idea, they draw 320 sprites (by page) to unscramble data...
Genius? :p
Do you have this duplicate frame on SW ?
No, it seems it's a scaling issue as it doesn't appear in HW native resolution either.
I have a dump for a similar issue on another game.
So Urban Chaos reads the 16 bits depth as a 8 bits index and store the result into a 32 bits color. I think the operation is close of that (mult and div through palette).
lsb = Depth & 0xFF;
msb = (Depth >> 8 ) & 0xFF;
color1 = (lsb / 7 ) + (lsb * 36)
color2 = (msb / 7) + (msb * 36)
But I miss somethings. The first draw which does the /7 gives a band rendering because of lsb/msb. But the 2nd part is normal.
Here a picture of the expected result after the 1st draw
And after the 2nd draw which does + color_index * 36
Or maybe the game try to do something like that lsb / 7 + msb * 36
. It would make more sense.
Depth is ABBBBBGG
GGGRRRRR
. It will make sense to shift the GreenRead part on the right. And the BlueGreen part on the left. So it roughly equivalent to (lsb >> 3) + (msb << 5).
Now I need to understand how we can select between lsb and msb so I can implement a hack for it.
Edit: so sampling line from [0;2] * N give you the LSB. And from [2;4] * N give you the MSB.
They don't make it easy do they lol
Hum it is even worse. What I did so far, is to detect the 8 bits effect, apply it to the full screen and skip the following draw call. Because they call it twice in a row, I can't do that neither. If I don't skip draw call, the texture cache will do extra lookup (huge memory consumption) and apply various conversion (huge gpu slowdown)... I need to implement something to handle offset inside the framebuffer. Ofc without breaking others renderers.
Call me weak, but I think I will put a CRC hack for this one. At least to drop the useless draw call. (well except CRC hacks are after texture lookup and not before...). What a mess.
OoO
Lookin' good! :)
And likely much faster than master (and even for normal gpu)
I'm trying to implement a solution to handle properly the top left corner post-processing effect. Let's centralize information here.
Game impacted (from the top of my head, likely more).
Better but still broken
Broken due to bad detection of the effect
Need test: