Tweak FBO sizing in FF crisis core/Last Ranker/Kingdom Heart

[dbz400]

Try to generate as small as possible FBO while maintains correct FBO sizing .This fixes FF Crisis Core , Last Ranker and Kingdom Heart.

[unknownbrackets]

I think this will never create one larger than 480x272, right? Won't that hurt GTA?

Also, I think for the stretching things, maybe we want to maintain aspect ratio rather than a straight up std::min/std::max on each component separately...

-[Unknown]

[dbz400]

Yes, even though used 480x272 , all games tested still render correctly .It would be good if can test GTA as well .

If 512x512 is used , Kingdom heart will have a black line on the left side so i think it need to be rendered exactly at 480x272

[unknownbrackets]

Hmm, I guess I did it wrong when I tried to make it only show 480px. It should only show the leftmost 480px in CopyDisplayToOutput.

Or is that with buffered rendering off? I didn't mess with the off path much.

-[Unknown]

[dbz400]

It is buffered rendering mode on . Bufferred rendering off is always correct as it got the fbo size return as 480x272.

[solarmystic]

@raven02

I merged your branch that contained this change (from patch-2) to the latest master (which was at v0.8.1-532-g3022a02 at the time of testing) to test this out myself.

It seems to work relatively well with a majority of the following 26 games I tested quickly, with a few exceptions:-

(FramebuffertoMem and FramebuffersCPUConvert hacks are always OFF unless explicitly specified)

Kingdom Heart Final Mix:- The black line on the right side is fixed, the map size that is drawn on the character's feet is bigger now. BR OFF fixes it as usual.

Crisis Core FFVII:- Also fixed. Proper shadows outside the Shinra building again. Still not quite as accurate as your previous solution but it's better than having it spread throughout the whole stage.

Danganronpa (tested with FB2MEM and FBCC hacks, required for it to work):-
Remains fully functional. No hang ups or crashes. Objects can still be scanned properly.

Legend of Heroes: Trails in The Sky (Both FB hacks are on for full transparency and save screenshot functionality):- Remains properly functional. Status menu is transparent and save screenshot works as intended.

Ys Seven (hacks are on, required for Minimap, and save screenshot functionality):- Minimap works, but is flickering. Text is displayed correctly in the status menu screen. Save screenshot works as intended. Big map is still not transparent, but that is due to a different issue.

Gods Eater Burst (hacks on):-
Game loads properly, missions load properly. No hangups or crashes. Excessive bloom still remains thanks to the previous responsible commits outlined in the issue report #2678 .

(GBE hacks off)
Same thing occurs. Excessive bloom is still seen in Gods Eater Burst.

Above observations in GBE are unrelated to this commit since the problem was already present in Orphis builds like 0.8.1-532 already before I merged your branch in for testing.

Hatsune Miku Diva 2nd:- Works fine, as usual

Black Rock Shooter:- Works fine, as usual

Persona 3 Portable:- Works fine, as usual

Monster Hunter Portable 3rd HD:- Works fine, as usual

Monster Hunter Freedom Unite:- Works fine, as usual

Tactics Ogre:- Now this is interesting. A regression happens here. Both the Square Enix intro logo video and the Basiscape intro logo video are now missing again just like in #2679

A comparison with a normal Orphis build (0.8.1-532) shows that it too is also missing the Square Enix logo now, but still displaying the 2nd Basiscape log video. I decided to do a bisect to find out the original revision that broke it again, and it's actually v0.8.1-531-g4c913c0 4c913c0 by @hrydgard that broke it.

v0.8.1-530-g79470e0 is the last one to properly display the logo. I thought about reopening the issue page again, but I think this is all related to this FBO issue.

Soul Calibur Broken Destiny (hacks used for proper screenshot functionality during Creation mode):-
Game works fine. Screenshot taking functionality works as intended; the picture taken is displayed properly with hacks on.

Tekken 5 DR:- Game works fine as usual

Tekken 6:- Game works fine as usual

Gundam V Gundam Next Plus:- Game works fine as usual

Final Fantasy I:- Works fine as usual

Final Fantasy II:- Works fine as usual

Final Fantasy III:- Works fine as usual

Final Fantasy Type 0:- Works fine as usual

Dissidia:- Works fine as usual (as compared to the latest Orphis builds)

Dissidia 012:- Works fine as usual. No better, no worse than before.

Persona 1:- Works the same like a normal Orphis build. No better or worse.

Persona 2:- Works the same like a normal Orphis build. No better or worse.

Patapon:- Works fine as usual.

Growlanser Wayfarer of Time:- The game loads properly, displaying the proper screens. Doesn't hang or crash on my system, even with the original PSP fonts. This is good progress for the game!

Conclusion:-

With the exception of the Tactics Ogre missing Square logo video regression (the regression started before the patch was applied anyway in the normal Orphis build -v0.8.1-532-g3022a02), the other games seem to tolerate this new patch well. No game is outright broken or unplayable, none crash or hang.

[dbz400]

I would like thanks again for the testing and it is very details as always .I think the new attempt by combining region and scissor test is working pretty well and even without set it to 512x512 texture size so performance should be good enough while still maintain correct rendering in most of the games.

For Tactics Orge, since i don't have this game , you may try to adjust those min/max to see what combination make it show the logo correctly. ( i think it broken becasue of using region to detect the texture size , or you can try to change to 512x512 in the else loop to see if it helps )

[dbz400]

@unknownbrackets , FYI, the black line on the left side becasue it created a FBO with size 512x272 .When it is render correct , it should be 480x272

40:49:026 user_main I[HLE]: GLES\Framebuffer.cpp:548 Creating FBO for 00044000 : 512 x 272 x 1
40:49:042 user_main I[HLE]: GLES\Framebuffer.cpp:548 Creating FBO for 000cc000 : 128 x 128 x 0
40:49:043 user_main I[HLE]: GLES\Framebuffer.cpp:548 Creating FBO for 000cc000 : 126 x 126 x 2
40:49:044 user_main I[HLE]: GLES\Framebuffer.cpp:462 Embiggening framebuffer (128, 128) -> (256, 128)

[hrydgard]

Well, it's a fact that GTA requires a render target of 512x320. Clamping to 480x272 just can't be right.

[dbz400]

I see .GTA seems to be pretty special to use 512x320 .If this is the case , i will change it back to use 512x512 .

[dbz400]

I think i understand what is the usage of throughmode here .Will perform more testing now :)

[solarmystic]

@raven02

I don't really get why all games don't just adhere to the one common single render target of 480x272 on the PSP. Would really make life a lot easier for emulators and emulation lol. Just set one resolution and you're done.

Anyway, keep up the good work.

[dbz400]

I just got GTA to test , it is a very tricky one of different FBO sizing ......

57:43:477 threadmain I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00000000 : 512 x 320 x 0
57:43:494 idle0 I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00178000 : 512 x 272 x 3
57:43:544 threadmain I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00088000 : 512 x 320 x 3

[VIRGINKLM]

@solarmystic I guess they do that sometimes also to attempt somekind of 1.5x SSAA?
Also wouldn't that reduce performance?

[hrydgard]

@VIRGINKLM exactly although I've only seen the GTA games use oversize rendertargets. And yes it costs power but GTA runs fast enough anyway on the real PSP, it's clear that fillrate isn't the bottlenck.

[dbz400]

Alright .This should be bit better including testing on GTA .Here is the testing build

[solarmystic]

@raven02

Thanks for the new test build, saves me the trouble of building it. Will run it through the same 26 games in my previous list.

[solarmystic]

@raven02

Here are the newest test results based on your provided build.

Since many of the test results from this build are actually still the same as the ones I posted before, I will only go into detail if there are any differences. "Same as before" means that its the same result obtained as the previous test I did on this page.

(FramebuffertoMem and FramebuffersCPUConvert hacks are always OFF unless explicitly specified)

Kingdom Heart Final Mix:- The black line on the right side is still fixed, the map shadow (glitch) that is drawn on the character's feet is even much more bigger now. BR OFF fixes it as usual.

Crisis Core FFVII:- Same as before. No changes

Danganronpa (tested with FB2MEM and FBCC hacks, required for it to work):-
Same as before. No changes.

Legend of Heroes: Trails in The Sky (Both FB hacks are on for full transparency and save screenshot functionality):- Same as before.

Ys Seven (hacks are on, required for Minimap, and save screenshot functionality):- Same as before.

Gods Eater Burst (hacks on):-
Same as before. Excessive bloom present.

(GBE hacks off)
Same as before. Excessive bloom present.

Hatsune Miku Diva 2nd:- Works fine, as usual. Same as before.

Black Rock Shooter:- Works fine, as usual. Same as before

Persona 3 Portable:- Works fine, as usual. Same as before.

Monster Hunter Portable 3rd HD:- Works fine, as usual. EDIT:- My mistake

Monster Hunter Freedom Unite:- Works fine, as usual. EDIT:- My mistake

Tactics Ogre:- Now this is interesting. The Square Enix logo and Basiscape logo is fixed! This is progress, well done!

Soul Calibur Broken Destiny (hacks used for proper screenshot functionality during Creation mode):-
Game works fine. Screenshot taking functionality works as intended; the picture taken is displayed properly with hacks on. Same as before.

Tekken 5 DR:- Game works fine as usual. Same as before.

Tekken 6:- Game works fine as usual. Same as before.

Gundam V Gundam Next Plus:- Game works fine as usual. Same as before.

Final Fantasy I:- Works fine as usual. Same as before.

Final Fantasy II:- Works fine as usual. Same as before.

Final Fantasy III:- Works fine as usual. Same as before.

Final Fantasy Type 0:- Works fine as usual. Same as before.

Dissidia:- Works fine as usual (as compared to the latest Orphis builds). Same as before.

Dissidia 012:- Works fine as usual. No better, no worse than before. Same as before.

Persona 1:- Works the same like a normal Orphis build. No better or worse. Same as before.

Persona 2:- Works the same like a normal Orphis build. No better or worse. Same as before.

Patapon:- Works fine as usual. Same as before.

Growlanser Wayfarer of Time:- The progress mentioned in my previous test report above is now back to square one. It is back to crashing PPSSPP everytime now on your build. Don't worry, it behaves this way too on a normal Orphis build so it is not a regression. #2675

Conclusion:-

Most games are working just like before. KH BBS is the only one with a graphical glitch that gets even worse with this commit.

All games suffer some performance hit, but it's minimal. Danganronpa in particular is the most affected since it requires both Framebuffer hacks to be on.

We need some Android users input on this method, since they will take the brunt of any performance regressions even worse that the Windows PCs.

[dbz400]

Thanks for testing .Good to hear Tactics Ogre got fixed. Regarding MH performance regission .I just seen the log and it only generate standard 480x272 FBO. Not much idea at this moment
.
btw, where i can see the map in KH? (i cannot see in mine)

　

[solarmystic]

@raven02

You should have a minimap on the top right hand of the screen. Even if it fails to display properly, it should be there.

EDIT:- Ah I see, you don't get a minimap until you properly start one of the three characters storyline. You need to progress a bit futher in the game (just skip through the tutorials). I would give you my save file but I'm playing the Japanese Final Mix version which uses a different save file.

[dbz400]

I see. btw , how is the slowdown compare to master build in MH ?

Besides, can you take a screenshot how it should look like in KH? (buffered rendering OFF)

[solarmystic]

@raven02

Very minimal, only around 5-10 VPS actually (when comparing a 32bit Orphis build with your 32bit test build).

I made a mistake and compared your build with a Orphis 64bit build which for some reason runs much faster on my system then a 32 bit Orphis build. (Monhun freedom unite VPS results:- 32bit Orphis 260 VPS, your 32bit build 250 VPS, the normal Orphis 64bit build 400+ VPS)

Which is why I edited that part of my test report with a "My mistake"

Sorry about that.

[dbz400]

I see. it is fine then . let see if @hrydgard and @unknownbrackets any comments on it .

[solarmystic]

@raven02

With buffered rendering OFF in KH, this is what it looks like on your provided testbuild:-

Zero shadows, but at least the glitchy ones don't appear anymore. I know this is incorrect, but it is preferable to the glitched minimap shadows.

[VIRGINKLM]

Speaking of shadows there was recently a pull request merged that included a supposed fix on the shadows on Final Fantasy Type 0 that said that fixed the dynamic shadows. It's not exactly correct, it tried to do something and you can see it but anyone else's shadow except the main character's is still the bonestructure and there are areas that you get a black texture under or a random texture under simmilarly to the bug of Kingdom Hearts Birth By Sleep.

[arnastia]

I don't know what it is you did in the past few days, but I noticed that for Ys Seven at least the emulator is guessing much larger sizes for some FBOs than before (not even the same aspect ratio on some anymore). For instance, one framebuffer was guessed at 64x64 and now is always guessed 480x272 (actually, they all are). This is with buffered rendering on and in both master and a build using the commit in this pull request.

[Squall-Leonhart]

The map/shadow issue seems linked to a buggish write back/reload framebuffer event.

sometimes you enter an area and the map/shadow is not present until you reach a point where enemies pop into existence.

[dbz400]

I think it is the best i can do at this moment and work for most of the games .For shadowing issue , we may have to live with it for a while until find out the root cause :(

@arnastia , unfornaturely i don't have that game to test it out but looks like the size return from either scissor or region greater than 64x64 , may be we need to include the size return from viewport as well.

drawing_width = std::min(512, std::min(scissorX2, regionX2));
drawing_height = std::min(512, std::min(scissorY2, regionY2));

[dbz400]

@arnastia , you can try this test build which incoporates comparsion using viewport , scissor and region all together therefore no more hardcoding 480x272,512x512 etc

[rename it to zip and extract]

[solarmystic]

@raven02

Nicely done. Using this latest build has yielded the following results for me using the games you have not tested:-

Ys Seven:- Yep. It's much better behaved now. The previous problems in your other test build (slowdown at the save screen and text issue after saves) have gone with hacks on.

Soul Calibur Broken Destiny:- Also okay with this build now. Doesn't crash like in the previous one. Screenshots taken appear properly for Creation Mode.with hacks on.

Legend of Heroes Trails In The Sky:- Behaves nicely with this build. Status menu background is properly transparent and the save file screenshots are taken properly with hacks on.

Monster Hunter 3rd Portable HD:- Behaves properly, even with hacks on. Everything works as intended.

Conclusion:-
This seems to be a good one. No problems here on my end. There also many other games I tested besides the listed ones, and they're all troublefree before this and after this, which is why I did not bother to list them.

Well done.

[dbz400]

Many thanks @solarmystic .I will now take a look the mipmapping issue for Tactics Ogre :)

[arnastia]

@raven02 If any of those that don't work are supposed to be using my framebuffer hacks, I think there is a problem with non 480:272 ratio textures in master that I probably fixed already, just haven't made a pull request yet.

[arnastia]

@raven02 I tried that last commit and Ys Seven is guessing 480x272 sizes for every framebuffer again.
Visually everything seems to work, but I gotta wonder if that's the correct value.

First a heads up, I'm using a version that changes some of my hack's code, but that hack should have no effect on the main framebuffers the emulator uses.

In both this version and the version using viewport as a minimum (which guesses some square textures) stuff seem to work, but I essentially use stride, height and format to determine the number of bytes to read from a framebuffer. So even though everything seems to be working more bytes are being read from the framebuffer and written to memory in one version than in the other.

For instance, in one version there are 128x128 ABGR1555 framebuffers with a stride of 128, meaning a total of 32768 bytes. In the other version these end up being guessed as 480x272 framebuffers with a stride of 128, so I end up doing the math with 128x272 ABGR1555, meaning a total of 69632 bytes being written to memory. If that size is wrong and any of that extra memory is not supposed to belong to this framebuffer, then I could end up overwriting another framebuffer's memory (or even pour out of VRAM, I guess?).

TL; DR: Can a framebuffer's width ever be greater than its stride? Because I think that's still happening in Ys Seven.

[dbz400]

I see. that's mean the different FBO size created from my different version will affect your code which written to memory.

For YS 7 , looks like it goto the non-through mode and set itself to always 480x272 . I will test this game soon :)

[dbz400]

@arnastia , btw , i just tested your new commit in your own repo , it works pretty well with those games previously have graphic here got fixed except for 3rd birthday .

[arnastia]

@raven02 Glad to know. As for 3rd Birthday, sorry, but I don't know what's wrong in that screenshot. Is it the minimap that should be displaying something else?

I'll hold off making a pull request for my code until we get this FBO sizing thing good to go since I may be doing something wrong.

[dbz400]

@arnastia , it is showing blue in color . Correct one is here

[arnastia]

@raven02 Ah, I see. Are you on an ATI? If so, are you using FramebuffersCPUConvert = True? Try to enable it even if you're on an Nvidia. Could be a framebuffer being read with switched color components.

[dbz400]

I'm using Nvidia . Just tried with FramebuffersCPUConvert = True however still blue color .

One positive result from read framebuffer to memory ON , the map in Tactic Orge show up pretty well although not 100% correct and pretty blurry.

[solarmystic]

@raven02

fyi in a current, normal Orphis build with the hacks on, this is what the 3rd birthday looks like.

[solarmystic]

@raven02

I think this is ready for merging if you aren't changing it anymore, and others don't have any objections to the commit.

[dbz400]

I should have nothing more to change at this moment .This one should generate least FBO size for correct texture display and should be most compatible so far .

[Ritori]

@raven02

is this commit will drop some speed just asking :)

[dbz400]

It shouldn't be as it already tested lots of games and it only generated least FBO size .

[Ritori]

I see.. thank for reply :)
my weak laptor realy need some speed up.

[dbz400]

The minimap shadow in Kingdom Heart is triggered by the viewport set in non-through mode .Try comment it out for testing and the the minimap shadow gone.of course break other games.

However not really sure how to proper fix it .

Before

.
After

[hrydgard]

Well, having no minimap shadow is probably not more correct really, it's good that it shows, it's just the wrong texture for whatever reason :P

[dbz400]

I totally agree .It just render somehow incorrect and one day we may be able to fix it .

[dbz400]

Just wider more testing in other forum .This fixes Hezy Force as well .

http://tieba.baidu.com/f?ct=335675392&tn=baiduPostBrowser&sc=35463518064&z=2457702097#35463518064

[hrydgard]

That commenting out those too lines fixes anything confuses me, but alright, I guess it will do for now, pending further investigation.

[dbz400]

@arnastia , i think you can pull out your new request for the non 480x272 texture fix in Read FBO to memory mode.

btw , under what suitation we should use FramebuffersCPUConvert = True ? (for ATI only) ?

[solarmystic]

@raven02

Yep, FramebuffersCPUConvert = True is mainly for ATI cards and Intel ones too. They need it ON together with FramebufferstoMem for the additional accuracy.

[dbz400]

I see. As @arnastia also mentioned to me try to turn it on for Nvidia Platform .I think for Android GLES2 , should be always ON ?

[solarmystic]

@raven02

Yes, Android platform need both on as well.

You can always turn it on for your NVIDIA card as well, to be sure.