Overbright issues.

[Kenny4343]

"EvilKingStan Wrote:
After [Unknown] fixed the lighting in rev v0.7.6-396-ga0e6917, everything is really over-bright in this game on android. (Especially the character models.) Not sure about other systems but it's definitely not right." (Kingdom Hearts BBS)

I thought it wasn't so bad once I noticed it on dissidia but it does indeed look over bright, most of the attacks and once you strike a finishing blow with some attacks it gets totally black/white and eventually fades, perfect examples are cloud cross-slash and lightning air square attack.

[solarmystic]

This issue has plagued other games in the past revisions, mostly solved by turning off buffered rendering.

Past examples include Wipeout games (Pulse and Pure) and Onechanbara Special, which needed buffered rendering to be off to solve the Overbright issues.

Not sure whether it's the exact same issue in this case though.

[jrdnwojcik]

The game I've found it's most noticeable in is Kingdom Hearts. Although it does show up in Dissidia to a lesser degree. Also, turning on buffered rendering only makes this worse. This is what happens in both Dissidia and Kingdom Hearts when BR is on.

[Kenny4343]

Some screenshots from Dissisidia, you can't apreciate it very well as I got pretty bad timing to take the screnshots, but the effects made right when the attack hits (overall hp ones) Get that bright that sometimes almost the whole screen gets all white or black, overall on finishing blows.

http://db.tt/U2pqT4qC http://db.tt/DbcZuBrF http://db.tt/BBwYD5K0 http://db.tt/0MS3Cy7J

[unknownbrackets]

I can revert it for Kingdom Hearts at least, although it'll be too dark then. Must be more logic to it...

-[Unknown]

[bsauvage1]

maybe worth trying as well for the glare issue in FF7CC ? (the first one mentionned in #1673 )

[dbz400]

I got some overbright issue as well on FF Type-0 below however it is casused by alpha doubling

    if (enableAlphaDoubling) {
        WRITE(p, "  v.a = v.a * 2.0;\n");
    }

[unknownbrackets]

What is the full blend mode in that case?

-[Unknown]

[dbz400]

I think you means what it should look like ? not quite familar with blend mode :(

[unknownbrackets]

If you do a "dump next frame to log" you should get a lot that contains "Blend mode:" in it. Somewhere in there should be a line where it says "2.0 * src.a" I'm wondering what the equation looks like.

For example, LittleBigPlanet did something similar, and it used "2.0 * src.a + 1.0 - src.a". Doubling made the vignette too dark.

-[Unknown]

[dbz400]

It is "2.0 * src.a , fixed" and "add src.a, 1.0 - src.a"

[dbz400]

I think correct one should "src.a , 1.0 - src.a" and shouldn't be 2.0 * src.a in this case .

[unknownbrackets]

Well, that's what the game is sending. So unless a CPU bug is making it generate the wrong thing, we can't just say "nope, you were lying" and change it.

Well, doubling would only affect the first one. Fixed colors always have 1.0 alpha (not sure if this is correct, but it makes sense?), but I'm not sure how multipling the alpha * 2 would change the color from black to white.

-[Unknown]

[dbz400]

Humm this "effect" is special sometimes white and sometimes black :)

[dbz400]

I remember this effect is introduced first from "Delay GPU signals and waits to simulate cycles."

The __GeTriggerInterrupt breaks it indeed

[unknownbrackets]

Random idea: I wonder if the brightness issues have something to do with "Reverse normal"? It was a change to the normal... hmm.

-[Unknown]

[hrydgard]

Hm, we do the reverse normal thing in the vertex decoder now instead of in the vertex shader which isn't really right as the reversed-ness gets cached, but if you disable the vertex cache you'll get the "correct" behaviour. If things are wrong with vertex cache disabled, reverse normals is not the culprit.

[Squall-Leonhart]

shadows are nuked as well.

Looks like 32bit jpcsp calculates vectors wrong too, it has the same colour glitches as 32bit ppsspp used to, though not the stretched banners

[solarmystic]

@Squall-Leonhart

I can confirm your observations for KH:BBS (US)

Using the latest revision (0.7.6-624), everything (character, background elements etc) seems to have an extra layer of brightness added to it. In addition to the usual menu UI tomfoolery when bringing up the status screen present in 32 bit builds.

[Squall-Leonhart]

it kind of looks like the kind of bug you would get by breaking multipass lighting in a pc game.

[Squall-Leonhart]

it is the removal of (from VertexGenerator.cpp) if (!hasNormal) continue; that causes the darkness, not "default normal to 0, 0, 1" With this back in place, the game isn't so bright is back, however it really does appear to be a mishandling of multipass lighting.

without it, the issue seems to be the fact that if (i == shadeLight0 || i == shadeLight1) doLight[i] = LIGHT_SHADE; is not working correctly.

[unknownbrackets]

It's only when gstate.getUVGenMode() == 2, which I'm not seeing Kingdom Hearts use.

But, isn't it too dark when the hasNormal check is added back? Maybe I'm wrong. It just seems like it's being applied too much, or something.

-[Unknown]

[Squall-Leonhart]

well going by this https://www.youtube.com/watch?v=umDyWFhvI8I

ppsspp would appear to be too dark, though im not sure if thats recorded straight from a psp or via jpcsp.

Is it possible that these games are using YUV color spaces and not being handled in RGB correctly?

Could it be an issue regarding emulation of the psp's brightness levels? It could also be post processing related (a suggestion from cottonvibes)

[Squall-Leonhart]

hmm, if you open the screenshot in paint.net or photoshop and edit the input levels down from 255 to 150-139, it starts to look correct....other than the hud being too bright lol....

[unknownbrackets]

Hmm. Map is also wrong. Should check if the game adjusts itself based on my brightness setting - it could be checking that using sceImpose or something, maybe.

-[Unknown]

[Kenny4343]

Yeah, I just started playing a bit ago and noticed that.

[Squall-Leonhart]

lol yeah, the map sometimes is rendered up in the top corner, but it usually turns black and ends up being rendered as the players shadow :|

[unknownbrackets]

More info: http://forums.ppsspp.org/showthread.php?tid=3810&pid=26261#pid26261

Some games are now brighter, and were exactly right before...

-[Unknown]

[solarmystic]

@unknownbrackets

When exactly were those "shadow effects" removed from the master build? If it could be returned to how it looked (like in those 0.7.5 screenshots in the forum thread you linked), wouldn't it be an improvement?

Unless of course it breaks other important functionality.

[hrydgard]

It has nothing to do with "shadow effects", it's just misbehaving lighting calculations. And as always when we don't have exactly the right solution, fixing it by reverting will break something else. Needs more investigation.

[Squall-Leonhart]

the removal of if (!hasNormals, blah) has caused issues in other games, i believe that should be reverted at least.

This games brightness is just (to a degree of 100-125points) too low.

[unknownbrackets]

If I remember right, Legend of Heroes: Trails in the Sky was clearly using lighting without normals to highlight menu buttons.

We can revert it but as @hrydgard said, it'll break that again and other games that use lighting without normals intentionally. We know that doing that does in fact work on the PSP because of that game, although we need more tests to see what's wrong.

KH is too dark without the brightness. My suspicion is that the lighting is simply being calculated incorrectly when there's no normal, but I don't know what the correct calculation is. I think turning it back off when there's no normal is probably not the right fix.

-[Unknown]

[Squall-Leonhart]

grumpy coder is providing some insight in the thread on the forum http://forums.ppsspp.org/showthread.php?tid=3810&pid=26470#pid26470

[Squall-Leonhart]

Brilliant, i'll move the shadows issues to a new issue then?

[unknownbrackets]

Yeah, I assume the shadows were broken before, you just couldn't tell, no?

-[Unknown]