Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gods Eater Burst (ULUS10563): Excessive bloom present in all PPSSPP builds since v0.8.1-361-gc71ae64 (updated, resolved in v0.8.1-401-g76c3f16, has since returned in v0.8.1-499-g72b13d9) #2678

Closed
solarmystic opened this issue Jul 7, 2013 · 15 comments

Comments

@solarmystic
Copy link
Contributor

UPDATE:- The bloom issue has returned again in v0.8.1-499-g72b13d9 since @raven02's pull request #2721 was merged into master 72b13d9 by @hrydgard

UPDATE 2:- New responsible commits are dca4b1e and 78f85db by @raven02

497

498

OLD ISSUE:-

The issue is as per the title. There is a severe case of bloom in the lighting especially evident in the main mission lobby.

The responsible commit is e362bc8

First problematic build to have it is v0.8.1-361-gc71ae64.

geb361bron

Last build not to have it is v0.8.1-356-g989f791.

geb356

Temporary Solution/Workaround:-

Disable Buffered Rendering and the issue will disappear,

geb361broff

@solarmystic
Copy link
Contributor Author

Resolved in v0.8.1-401-g76c3f16. Closed.

@triglav1024
Copy link

Recurrent on v0.8.1-503-gbf1e076.
screen00000

@solarmystic
Copy link
Contributor Author

@triglav1024

You're right, it has returned, but actually started returning again in v0.8.1-499-g72b13d9 since @raven02's #2721 pull request was merged into master 72b13d9 without any hacks and with BR ON.

499gebbloom

Temporary solution:-

OFF BR and it will go away again

499gebbroff

Last working revision not to have this issue with BR ON is v0.8.1-496-g7c3e171

496gebbronnobloom

Reopened issue since it has returned in all revisions after v0.8.1-499-g72b13d9 again, without any Framebufferhacks applied to the game.

@solarmystic solarmystic reopened this Jul 10, 2013
@solarmystic
Copy link
Contributor Author

In the process of pinpointing the direct responsible commit down, I decided to compile 2 separate builds from each of @raven02's commits, 1 from v0.8.1-497-gdca4b1e and 1 from v0.8.1-498-g78f85db, and then test them both separately to see which one was the responsible one.

To my surprise, v0.8.1-497-gdca4b1e dca4b1e still looks somewhat okay:-

497

v0.8.1-498-g78f85db 78f85db was the one that made it excessive:-

498

So both dca4b1e and 78f85db by @raven02 are responsible, but by different degrees.

No Framebuffer hacks were used in these tests. Just BR ON.

@raven02
Copy link
Contributor

raven02 commented Jul 10, 2013

I think @hrydgard have been rewritten all of these for both SW & HW here bf1e076

Basically those effect are 'side effect' of correct FBO sizing and that's why it is not happened before .

I did checked this game and it has bloom effect all around the games and similar to 1st screenshot .

@solarmystic
Copy link
Contributor Author

@raven02

The point is that the excessive bloom re-occured again on git revision v0.8.1-499-g72b13d9 which you were responsible for (using HW and SW) and before @hrydgard rewritten them for HW in v0.8.1-503-gbf1e076

Which is why I traced it back to your precise commits in v0.8.1-497-gdca4b1e and v0.8.1-498-g78f85db.

They still happen in the latest revisions btw.

@solarmystic
Copy link
Contributor Author

Still present in the latest Orphis build (v0.8.1-557-gb039768), with BR on:-

gebbron

BR off:-

gebbroff

@raven02
Copy link
Contributor

raven02 commented Jul 14, 2013

I think we are come close to be correct . In real PSP , those bloom effect is emitted from those windows above .

1

This is PPSSPP at same angle in-game
screen00000

@raven02
Copy link
Contributor

raven02 commented Jul 30, 2013

I'll goto revisit that render-to-texture sizing tonight . Seems to me that we still have bit wrong sizing .

This screenshot looks to me that renders the bloom effects more correctly (provided by @solarmystic)
d63e616e-e961-11e2-96eb-a5a1e77a2904

@unknownbrackets
Copy link
Collaborator

Yeah, that's weird that that one commit would've changed things.

-[Unknown]

@raven02
Copy link
Contributor

raven02 commented Aug 9, 2013

I do wonder the above screenshot only renders the bloom effect at the top left corner only as the right console is no bloom effect at all .

@thedax
Copy link
Collaborator

thedax commented Dec 6, 2013

The excessive bloom is gone in buffered rendering mode now, so this can be closed, I'd think.

@solarmystic
Copy link
Contributor Author

Yeah. Will reopen if the issue recurs.

@unknownbrackets
Copy link
Collaborator

And broken again now because apparently we want to not zero when the pixels we don't draw are supposed to be not zero, which I don't understand.

-[Unknown]

@hrydgard
Copy link
Owner

hrydgard commented Dec 8, 2013

Reverted commit that broke it. Need to have another look at that stencil workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants