Another attempt at framebuffer size estimate changes #6211
Conversation
To avoid cases where they remain too small, and to make sure size always matches up sanely.
This avoids a blink when sizing up.
|
Looks good, and blitting on fb resize is a good idea/fix. I'll merge when test results look good. |
Even if it's wider but short, it should not reduce the height of the buffer.
|
@hrydgard @unknownbrackets Did the usual
General observations:- a. Valkyrie Profile Lenneth is improved, but contrary to what is mentioned in the pull request, the ingame video playback is still broken for me in the test build. Notable mentions include the Lenneth Valkyrie Transformation scene and the opening gates scene in the beginning. Only a black screen is seen where the videos were supposed to be played, but gameplay resumes as normal after a short while. One can still hear the video's audio being played in the background though.
b. All other games in the list are unaffected by this change, those that were working are still working just fine after applying this pull request to the current master. |
Instead, draw in the top corner. This way, even if framebuffers get smaller things stay consistent.
|
Oh, it seems like it now requires "simulate block transfer", but that's previous to these changes. Anyway, sorry. I've made more major changes which seem to resolve things for me in a way that makes a lot more sense to me logically. Now we just take the width/height of the framebuffer from the corner of the FBO and have fun. I double checked 3x etc. and read framebuffers to memory and blitting, but it's very possible I broke something. So many places that were treating vfb->width as the FBO width...
-[Unknown] |
|
Not too sure if it is my own issue ? i got wrong color elsewhere (R/B swapped) |
|
And that only happens with these changes merged? This shouldn't be able to affect that... -[Unknown] |
|
Yep , i just tried latest master build , it is okay .Let'see if other can reproduce it or may be just my own issue. |
|
That's... weird. Can you bisect it? Which commit did it start with? -[Unknown] |
|
Sure let me check .(However , i think it is fine on your side?) |
|
dragon ball looks fine |
|
You don't have the "inverse colors" post-processing shader selected, do you? -[Unknown] |
|
I tried to rebuild the source again , it is fine now :) strange. |
|
@unknownbrackets Yeah, I just retested Valkyrie Profile again using Simulate Block Transfer and now the video playback is perfect. I'll have to make a note of that. |
|
One thing I'm not sure about is if I need to adjust the scissor coordinates too. I'm a little confused about what things are relative to... -[Unknown] |
|
@daniel229 how are the Natsuyasumi with the latest changes? -[Unknown] |
|
No changing. |
|
Natsuyasumi 1 |
|
natsuyasumi 4 |
|
Log from both games with this line at the end of EstimateDrawingSize() would help the most: NOTICE_LOG(SCEGE, "%08x V: %ix%i, R: %ix%i, S: %ix%i, STR: %i, THR:%i, Z:%08x = %ix%i", gstate.getFrameBufAddress(), viewport_width,viewport_height, region_width, region_height, scissor_width, scissor_height, fb_stride, gstate.isModeThrough(), gstate.isDepthWriteEnabled() ? gstate.getDepthBufAddress() : 0, drawing_width, drawing_height);It looks like they are both using 481x273 framebuffers though. -[Unknown] |
|
natsuyasumi 1 ntsuyasumi 4 |
|
Okay, I'm just going to force 481 -> 480, since I've seen that behavior also in Jewel Summoner, and it's clear there aren't 273 lines of VRAM. -[Unknown] |
|
natsuyasumi games looks good now,however I found previous unknownbrackets@c2ccfd5 breaks Castlevania Rondo of Blood original,black screen. add that NOTICE_LOG |
|
Oh okay, I'm back. So, if you force the width to let's say 480, does it work? Reverting that part just prevents it from shrinking the active portion of the framebuffer... it theoretically should not be able to make the screen black... Maybe it's scissor, somehow... Does this or some demo do it? Or is it not the same game? -[Unknown] |
|
480 works |
|
Yes,that's the same game,and seems no demo for it.Rondo of Blood is something unlocked from the game. |
|
I see. Grr. Is it doing any block transfers? In Core/Reporting.cpp, replace Oh. What if you change But even if that does work, theoretically it will not be full screen... is it "pillarboxed"? -[Unknown] |
|
if (MaskedEqual(v->fb_address, addr)) works |
|
the game is never full screen like you said |
Castlevania actually uses a display buffer of 420, it seems. Since we no longer allow multiple FBOs at the same address, this should be safe.
|
Cool. So those games are all working? This stuff is so complex and inexact... -[Unknown] |
|
Yeah. |
|
Anything known remaining before a merge? |
|
Meh, I'll merge. As always, we'll see if there's any fallout... |
Another attempt at framebuffer size estimate changes
|
For the record, this neither helped nor hurt Breath of Fire 3, so that's something. |
|
This pull request destroyed God of War Ghost of Sparta's performance. From 120 fps to 60 fps on the starting area. Otherwise, it is great. Good work. |
|
@DonelBueno I can verify this finding. Performance loss is almost half, as you experienced. v0.9.8-995-g84ff3d6 (before the commit) 71 VPS v0.9.8-1018-g318f641 (after the commit) 47 VPS |
|
My GPU usage is way bellow 100% in both cases. I bet you could get a good improvement on the first screenshot with a lower rendering resolution. Can you check the drawcalls in both scenarios? |
|
@DonelBueno I intentionally created a GPU limited situation for performance testing (using 3x rendering resolution) to minimize the CPU's influence on the emulation. And it makes sense in this case, since it's a framebuffer size commit which would impact GPU performance that is responsible for the reduction. All settings are the same between both tests. |
|
As I said, in my case I was limited by the CPU in both tests (My GPU usage was about 20-35% in both tests, closer to 20% in the first one), so it obviously affects CPU performance. That's why I asked you to check drawcalls, which are very CPU dependent. |
|
@DonelBueno I had a look at the drawcalls and it was above 19000 for both cases. EDIT:- No, that's incorrect, during the actual fight scenes (when you get to control Kratos) it drops down to nearly half that (~11k), but it fluctuates rapidly. |
|
Hmm. As long as I have simulate block transfer off in God of War, performance doesn't seem to be any worse than before on master with this merged... -[Unknown] |
This needs testing, and probably there are things that don't work. I tried to expand the logic that guesses at the size of a framebuffer to cover the cases I could see.
This fixes the broken games in #6093 for me. It does make the Valkyrie Profile video correct as well, but I'm not sure if there's still an issue there since videos maybe ought to "prompt" the resizing code... this can mean framebuffers remain a bit larger, though, hmm.
@solarmystic, if you could test some games with this it'd be a real help.
-[Unknown]