Avoid blitting for a bunch of gpu blending modes #6350
Conversation
We're not doubling the alpha, so all these cases are safe regardless of the alpha value.
These prevent the need for more blits.
| } else { | ||
| glstate.blendEquation.set(eqLookupNoMinMax[blendFuncEq]); | ||
| void TransformDrawEngine::ApplyDrawState(int prim) { | ||
| // TODO: All this setup is soon so expensive that we'll need dirty flags, or simply do it in the command writes where we detect dirty by xoring. Silly to do all this work on every drawcall. |
There was a problem hiding this comment.
This is an old comment but it's just getting truer, heh.
There was a problem hiding this comment.
Heh. I tried to keep the changes light as possible, but yeah... this is true.
-[Unknown]
There was a problem hiding this comment.
Yeah, not singling out this change or anything, it should be fine.
|
Nice idea to use src alpha like that for the fix blends. |
Avoid blitting for a bunch of gpu blending modes
|
Yes,Gensou Suikoden 1&2 speed back.Are these black boxes blending issue. |
|
Seems likely to be a blending issue, yes. Check the graphics debugger when they are being drawn. |
|
|
|
and this |
|
Hmm, alpha test requires that it's ==ff...? Ugh, this is doing that same every other junk. Did it work before? Which commit broke it? It seems like bogth cases should use color doubling. I'm worried the dst.a (stencil) may be wrong. What does the stecnil test look like during these draws? -[Unknown] |
|
Tested several builds since 0.9.6,still not works.stecnil test disable. |
|
Maybe it never sets the stencil at all. Hexyz Force had a function that cleared buffers right at the start, and set the stencil to 0xFF. We ended up making buffers default to that. It's not really correct, though. Perhaps this game expects it to default to 0. Does anything change if you replace these lines in Framebuffer.cpp: glstate.stencilFunc.set(GL_ALWAYS, 0xFF, 0xFF);
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClearStencil(0xFF);With: glstate.stencilTest.disable();
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glClearStencil(0);Or is it still the same? -[Unknown] |
|
Yes,It fixes all graphical issues including #6226 |
|
Oh, cool. I think it makes more sense to default buffers to 0 - or technically, we should initialize stencil to whatever is in that channel of memory behind the buffers when they are created. Could use the same trick unknown invented for Star Ocean. Or maybe hexyz needs a function replacement? |
|
I think Hexyz just needs function replacement. It actually looked like a function likely to be used by other games (it had an FBO struct and etc.) One game has the same issue with depth iirc. -[Unknown] |
|
and fixes this #5205 |
|
Hm, looks like the blur gets disabled altogether, instead of only being far away. But I guess that's better than a full screen blur, heh. |
|
Yes,it's better than full screen blur.another game gets the same thing. |
|
What do those scenes look like on a real psp? -[Unknown] |
|
On psp. On ppsspp missing blur on the ground |
|
Does it look right in the software renderer at least? Could be something stencil related still... I do think that uploading memory to FBOs on create makes sense. Even downloading on destroy could, but sounds ultra dangerous (although there may be ways to be more sure.) Would possibly fix effects especially on savestate/pause. -[Unknown] |
|
software renderer is broken, |
|
After loading savestate,no difference. |
This avoids the copy for a ton of blending modes, which should take care of these situations:
http://report.ppsspp.org/logs/kind/622?status=any
(as you can see some were quite bad...)
Specifically:
Additionally, uses the blit/shader for min/max when unsupported. Of course this might be slower on such devices, but it doesn't seem like one or two blits are too bad (as long as it doesn't get out of control), and this should fix effects.
I haven't tested a ton of games but I tested several that triggered these more unique blending modes.
-[Unknown]