Tactics Ogre: Multiple Graphical Issues

[TallgeeseHeaven]

Initially this issue note was for the world map, but it was deemed to be better to consolidate all of this game's various graphics issues into one ticket.

First, attached is a screen of what the world map looks like on a PSP system:

Buffered rendering of this map has had around five distinct stages. I hope that this is helpful in diagnosing the issue.

Stage 1: Completely black screen except for the text.

Stage 2:

All further screens are with Buffered Rendering ON and Skip Updating PSP Memory OFF. This is from around when Skip Updating PSP Memory was first implemented:

Stage 3: https://github.com/hrydgard/ppsspp/commit/0eadfdcf62f8a60dfb2f83243ad9c700acc55bec

This commit suddenly breaks the map. Result:

Stage 4: https://github.com/hrydgard/ppsspp/commit/76c3f16b5cf238a8c6548d05e4873b9a2ef1f7b2

This commit makes the map display again, like so:

Stage 5: https://github.com/hrydgard/ppsspp/commit/605cf266211d4630800da2cbcc9cda53b0953378

This reversion breaks the map again, returning us to Stage 3. This is where it remains as of the latest GIT build, as well as raven02's recent build that fixed the logo.

I have an HD Radeon 7850, if that matters. If there is any other information I can give, please ask.

[raven02]

@TallgeeseHeaven , be reminded that all testing should be performed with 'Skip Updating PSP memory' OFF and buffered rendering ON .

You can try this test build to see if this help , it is compiled from #2747

[rename to zip and extract]

[Abalieno]

It does nothing. In the sense that when zoomed in the map always goes dark regardless of settings, or test build.

[TallgeeseHeaven]

@raven02 : All of these screens except for the first one (which is how it looks on a PSP) are with the settings you mentioned at various builds. Skip Updating PSP Memory is OFF, Buffered Rendering is ON. Sorry for not being clear, I'll edit the post.

The build you posted is the same as the mostly black screen under Stage 3, namely this one:

[raven02]

I see and thanks for testing . I will soon test this game then to see what is the underlying issue . Just wonder which build you test that show correct one in stage 2 ?

[TallgeeseHeaven]

There are also issues with various ingame magic spell effects and battle swirls. Should I make a separate issue for those?

[raven02]

I think it would better put all the issue here in single page and easy to follow .It would be good if you can get the log for stage 2 (correct) and stage 5 (incorrect) , then we can know what FBO size is the correct one .

[TallgeeseHeaven]

@raven02 : I run Log.bat for that, right?

Also, Stage 2 isn't quite correct, it's pretty close though.

This is what's fully correct, notice the transparent blur effect on the bottom of the screen:

This is Stage 2:

[raven02]

Yes, log.bat

[TallgeeseHeaven]

@raven02 Right, here you go. Hopefully this is the right way to post this:

---

Stage 2:

11:22:543 taco_thread I[HLE]: HLE\sceGe.cpp:465 sceGeEdramSetAddrTranslation(1024) 11:22:543 taco_thread I[HLE]: GLES\Framebuffer.cpp:501 Creating FBO for 00000000 : 480 x 272 x 1 11:22:576 taco_thread I[HLE]: GLES\Framebuffer.cpp:501 Creating FBO for 00088000 : 480 x 272 x 1 11:22:580 taco_thread I[HLE]: GLES\Framebuffer.cpp:501 Creating FBO for 00044000 : 480 x 272 x 1 11:22:642 idle0 I[HLE]: GLES\Framebuffer.cpp:960 Decimating FBO for 00000000 (480 x 272 x 3), age 7 11:22:651 taco_thread I[HLE]: HLE\scePower.cpp:204 sceKernelVolatileMemTryLock(0, 09fff360, 167768932) - success 11:22:653 taco_thread I[HLE]: HLE\scePower.cpp:222 sceKernelVolatileMemUnlock(0) 11:22:659 idle0 I[HLE]: GLES\Framebuffer.cpp:960 Decimating FBO for 00088000 (480 x 272 x 3), age 8 11:22:776 taco_thread I[HLE]: HLE\sceGe.cpp:465 sceGeEdramSetAddrTranslation(1024) 11:22:776 taco_thread I[HLE]: GLES\Framebuffer.cpp:501 Creating FBO for 00000000 : 480 x 272 x 3 11:22:810 taco_thread I[HLE]: GLES\Framebuffer.cpp:501 Creating FBO for 00088000 : 480 x 272 x 3 11:22:860 idle0 I[HLE]: GLES\Framebuffer.cpp:960 Decimating FBO for 00088000 (480 x 272 x 1), age 6 11:22:875 idle0 I[HLE]: GLES\Framebuffer.cpp:960 Decimating FBO for 00000000 (480 x 272 x 1), age 7 11:22:894 idle0 I[HLE]: GLES\Framebuffer.cpp:960 Decimating FBO for 00044000 (480 x 272 x 1), age 8 11:23:018 taco_thread I[HLE]: GLES\Framebuffer.cpp:501 Creating FBO for 00110000 : 480 x 272 x 3 11:23:021 taco_thread I[HLE]: GLES\Framebuffer.cpp:501 Creating FBO for 00132000 : 480 x 272 x 3

---

Stage 5:

21:07:298 taco_thread I[HLE]: HLE\sceGe.cpp:465 sceGeEdramSetAddrTranslation(1024) 21:07:299 taco_thread I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00000000 : 480 x 272 x 1 21:07:338 taco_thread I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00088000 : 480 x 272 x 1 21:07:339 taco_thread I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00044000 : 480 x 272 x 1 21:07:398 idle0 I[HLE]: GLES\Framebuffer.cpp:1166 Decimating FBO for 00000000 (480 x 272 x 3), age 7 21:07:403 taco_thread I[HLE]: HLE\scePower.cpp:204 sceKernelVolatileMemTryLock(0, 09fff360, 167768932) - success 21:07:405 taco_thread I[HLE]: HLE\scePower.cpp:222 sceKernelVolatileMemUnlock(0) 21:07:416 idle0 I[HLE]: GLES\Framebuffer.cpp:1166 Decimating FBO for 00088000 (480 x 272 x 3), age 8 21:07:485 idle0 I[HLE]: GLES\Framebuffer.cpp:1177 Decimating FBO for 00088000 (480 x 272 x 3), age 6 21:07:485 idle0 I[HLE]: GLES\Framebuffer.cpp:1177 Decimating FBO for 00000000 (480 x 272 x 3), age 9 21:07:535 taco_thread I[HLE]: HLE\sceGe.cpp:465 sceGeEdramSetAddrTranslation(1024) 21:07:536 taco_thread I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00000000 : 480 x 272 x 3 21:07:581 taco_thread I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00088000 : 480 x 272 x 3 21:07:616 idle0 I[HLE]: GLES\Framebuffer.cpp:1166 Decimating FBO for 00088000 (480 x 272 x 1), age 6 21:07:638 idle0 I[HLE]: GLES\Framebuffer.cpp:1166 Decimating FBO for 00000000 (480 x 272 x 1), age 7 21:07:649 idle0 I[HLE]: GLES\Framebuffer.cpp:1166 Decimating FBO for 00044000 (480 x 272 x 1), age 8 21:07:688 idle0 I[HLE]: GLES\Framebuffer.cpp:1177 Decimating FBO for 00000000 (480 x 272 x 1), age 6 21:07:688 idle0 I[HLE]: GLES\Framebuffer.cpp:1177 Decimating FBO for 00088000 (480 x 272 x 1), age 6 21:07:688 idle0 I[HLE]: GLES\Framebuffer.cpp:1177 Decimating FBO for 00044000 (480 x 272 x 1), age 6 21:07:776 taco_thread I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00110000 : 480 x 272 x 3 21:07:776 taco_thread I[HLE]: GLES\Framebuffer.cpp:554 Creating FBO for 00132000 : 480 x 272 x 3

---

[Abalieno]

I had one opened a while ago for spell effects being wrong: https://github.com/hrydgard/ppsspp/issues/2667

[TallgeeseHeaven]

@Abalieno What I'll try to do is get a screenshot of what various spells are supposed to look like when we get to that, so that raven02 knows what to look for.

[raven02]

Many thanks .looks like both render 480x272 but wrong one seems to be decimating a lot . @unknownbrackets t , what do you think?

[raven02]

I hope this is not ATI issue .any other pp who can test against nvidia card?

[solarmystic]

@raven02

Would like to test this but I'm also having an ATI card. Have you read my latest report in your issues thread yet?

[TallgeeseHeaven]

@raven02

You typoed @unknownbrackets name, in case you're trying to call him here. I'm new to this issue system, so not sure how it works.

[raven02]

I just found there is one more issue when mipmapping ON .

-ON

-OFF

[solarmystic]

@raven02

That is a well known issue, and related to this https://github.com/hrydgard/ppsspp/issues/2286

[raven02]

@solarmystic . I see. Thanks.

@TallgeeseHeaven , which revision you use to generate stage 2 ?

[raven02]

This game is crazy .It need FBO height more than 544 to render this map correctly.

Bascially , viewport/scissor/region all return 480x272 only ........how to do ?

48:57:830 taco_thread I[HLE]: GLES\Framebuffer.cpp:392 Viewport : 480/272 , Scissor 480/272, Region 480/272

[TallgeeseHeaven]

@raven02

I apologize for the delay in my response, I was out. GIT revision v0.8.1-231-g5156f12 is good for Stage 2. It stays in Stage 2 until commit https://github.com/hrydgard/ppsspp/commit/0eadfdcf62f8a60dfb2f83243ad9c700acc55bec .

[TallgeeseHeaven]

@raven02 I should tell you, the latest build you posted in https://github.com/hrydgard/ppsspp/pull/2747 has some nasty behavior on the map.

If Read Framebuffers to Memory happens to be On at any point when the map is loaded, turning Buffered Rendering to Off will result in the map staying broken. If you turn Read Framebuffers to Memory Off afterwards, it doesn't fix it either. You have to keep it off the whole time.

[raven02]

Yep , the map is not gonna fixed as it requires bigger size of FBO to render it correctly in buffered rendering mode . The only correct one now is in non-buffered mode . This is from official build 549

[TallgeeseHeaven]

Yeah; I was just saying that if Read Farmebuffers to Memory is on, turning Framebuffer Rendering Off won't render it correctly.

[raven02]

I think the question is ... anything fixed if this option on ? If not , simple turn it off is ok.

[TallgeeseHeaven]

Should I start listing the various spell casting problems with Read FB to Memory now, or wait until the map is fixed then?

[raven02]

Do you mean the Read FP to memory fix the spell casting ?

[TallgeeseHeaven]

You need Read FB to Memory ON in order to show battle begin swirling effects and various spell effects. They just look messed up in various ways.

Leaving Read FB to Memory OFF takes out these effects. The problem is, this results in some spells blacking out the whole screen while they're being casted.

[raven02]

Alright .Then we need that option . I think you are meaning this effect .

[TallgeeseHeaven]

Yeah, among others. Try the spell "Paralytic Wave", as well as when you start a fight in other areas. The name of the battlefield comes up, blacks out a moment, then the name swirls around.

I can get you a US save in which a necromancer casts a long spell with messed up colors. Would that be helpful?

[TallgeeseHeaven]

EDIT: Sorry for kicking this issue up the thread. I was updating the title to make it more general.

@raven02

https://github.com/hrydgard/ppsspp/commit/b039768b2d876e71c7b645d73c7d1513a958d4ad

Your pull above (https://github.com/hrydgard/ppsspp/issues/2772), which fixes depth issues in various games, introduces a regression in certain scenes of Tactics Ogre. See this screenshot, where characters are now suddenly standing on the table. This issue was not present previously.

Would a log or a save for this be helpful?

[raven02]

A save would help . I can test which logic break it

[TallgeeseHeaven]

@raven02

http://www.mediafire.com/?yotjs2upcy4deap

Here is a US save.

To see a scene in question, press X, go to the Warren Report, go to Tidings, then view "The Impatient Duke".

What will make fixing your fix more complicated is that it appears that the depth fix corrects certain spells and abilities which black out the whole screen otherwise. To see one of those, go into a battle with Canopus (try the Phoranpa Wildwood), fight until his yellow TP bar reaches 100, then use his Finishing Move, Brimstone Hail.

[raven02]

Thanks for the save .Will check this out .

[raven02]

I just go into more deep testing on it .Looks like even though git build 231 , BR ON without read FBO to memory is also rendering incorrectly like this one

[solarmystic]

@raven02

The depth issue in Tactics Ogre has been fixed with https://github.com/hrydgard/ppsspp/commit/dfb598381667b07ef0f13389e65959dd457d4180

Characters are positioned properly again, and do not stand on tables

[raven02]

Good to hear .At least this is back to normal .

[raven02]

@solarmystic .Here is the test build for fixing the Untold.Legends.2.The.Warriors.Code

Can you help to test it if it fixes the depth issue in Tactics Ogre as well ?

[solarmystic]

@raven02

Thanks for the test build. Will report back after I'm done testing.

[solarmystic]

@raven02

Using the test build, the depth issue in Tactics Ogre is still fixed:-

And the Untold Legends game that has issues is actually the 1st one, known as Brotherhood of the Blade, not the second one (which you stated in your post). They are 2 different games all together, but anyway, it seems like the build fixed the problem anyway, and the characters are now visible, well done :-

Do you want me to test any other games?

[raven02]

Humm i think should be good enough .Basically i revert the depth fix back to square one :)

[solarmystic]

@raven02

What about the other games that needed it in the first place, like Saint Seiya? Would it have missing characters again?

I remember this https://github.com/hrydgard/ppsspp/pull/2580 ,which is the one that started it all.

If you revert the depth fix to square one, the following games you fixed before might have issues:-

1. Saint Seiya Omega might be affected
2. Gundam AGE Universe might be affected
3. Ridge Racer might be affected.

I don't have the first 2 games, should you should test them first with your current test build to make sure they won't have disappearing characters again.

[raven02]

RR2 is okay .For Saint Seiya Omega & Gundam AGE Universe , i'm pretty sure it need a single identifier to set it depth value GL_TRUE thoughout the game however i still cannot figure out ........

@hrydgard , the only difference i can see on Saint Seiya Omega & Gundam AGE Universe , they are all using render-to-texture however what identifier we can use it to set depth to GL_TRUE ?

[TallgeeseHeaven]

Very nicely done, thank you. Mipmapping is fixed, as is the map rendering with FB Rendering on. As far as I know the only things left are making Read FB to Memory cooperate for various effects (having it on still breaks the map, sadly), and this one little issue I thought was related to the mipmapping but isn't. I'll point it out now.

Look at this image again:

Look right underneath the name "Duke Ronwey". When a character's name is rendered in scenes, the text is supposed to have a drop shadow rendered underneath. The shadow is broken up. May have to zoom in to see it; it's more noticable in non-flashback scenes, since they don't have the sepia tone. It's a minor thing, but an anomaly all the same.

[TallgeeseHeaven]

Ah, I forgot. One more thing.

Load the save I gave above, go into a battle, deploy the mage named Wolfstan, and check out his Act menu in battle. It turns out that if you have enough available actions that you need to scroll the icons, a very ugly black line gets generated across about a third of the screen.

[raven02]

I think this issue should be completely fixed now with correct map and blur effect .Thus , can be closed.

[solarmystic]

@raven02

Thankfully the issue report hasn't been closed. I'd like to add a new graphical issue that I've just discovered in the world map for Tactics Ogre. The world map now flickers like crazy when first entered after loading any savegame that takes you straight to the world map.

This issue was discovered when I was running my usual test suite for @raven02's latest commit https://github.com/hrydgard/ppsspp/pull/3598#issuecomment-23721489 and it turned out that it was also present in the latest master too. (v0.9.1-487-g728e1a5)

A git bisect lead to the original responsible commit which is https://github.com/hrydgard/ppsspp/commit/ac56a7ee65c8c48d9742f82d106ff6ff47267504 in v0.9.1-421-gac56a7e by @unknownbrackets

Last working build is v0.9.1-420-g49902ed https://github.com/hrydgard/ppsspp/commit/49902ed4dcc5504c1fc164f9ac4c312a57c4ee19

I tried uploading a youtube video but it won't show the flickering after youtube does it's own alterations to the video captured using FRAPS (video taken in 60 FPS, youtube compresses it down to 30 FPS, flickering disappears), but I can assure you it does happen and it's very easily reproducible:-

1. Start up the game in any revision after v0.9.1-421-gac56a7e with default settings.
2. Load a savegame that'll bring you straight to the world map. Or use mine, http://www.mediafire.com/?d54579kss8bt7cw
3. Witness the flickering.

What's interesting is that if I re-encode the FRAPS capture myself from 60 FPS (original framerate from the capture) to 30 FPS, the flicker also disappears in the resulting video.

Temporary solutions to resolve the flickering for now:-

1. Enter another place (shop, castle etc) and exit back to the world map.
2. Change rendering mode from Non buffered to buffered again, or change the size of the screen (windowed to full screen, 1x -> 2x -> 3x etc)

Logfile:- https://gist.github.com/solarmystic/6426513

[unknownbrackets]

So probably the framebuffer it's referencing is no longer alive but we don't know it yet... Maybe it should only keep it alive if it was rendered to the same frame when first attaching, or something...

Or maybe we should use a sentinel pixel at the top left of render FBs and if they are changed we know there's something amiss?

-[Unknown]

[solarmystic]

As a follow up on my previous comment in this issue report https://github.com/hrydgard/ppsspp/issues/2758#issuecomment-23725775 , I forgot that I could've just uploaded the video files to a file hoster (not Youtube) to maintain the 60 FPS format so that you can witness the flickering as it is seen in the original videos.

And here they are, for your perusal.

Download the video files and play them back in your preferred media player, they're just MP4 container files encoded in .h264 (x264) and AAC audio using Handbrake to save space. The file sizes are only 1-3 MB approximately.

v0.9.1-421-gac56a7e https://github.com/hrydgard/ppsspp/commit/ac56a7ee65c8c48d9742f82d106ff6ff47267504 (flickering in the world map upon first entry) http://www.mediafire.com/?gf0navzfs4hufy0

v0.9.1-420-g49902ed https://github.com/hrydgard/ppsspp/commit/49902ed4dcc5504c1fc164f9ac4c312a57c4ee19 (no flickering in the world map) http://www.mediafire.com/?d8s52z63hne6gcx

[raven02]

@unknownbrackets , comment out the following keep alive framebuffer , fix it .However , not too sure if it will break the others.

        // Keep the framebuffer alive.
        // TODO: Dangerous if it sets a new one?
        //entry->framebuffer->last_frame_used = gpuStats.numFlips;

[raven02]

or remove the entry->invalidHint == -1 also fixes the issue

         if (!entry->framebuffer || entry->invalidHint == -1) {