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: 0eadfdc

This commit suddenly breaks the map. Result:

Stage 4: 76c3f16

This commit makes the map display again, like so:

Stage 5: 605cf26

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.

[dbz400]

@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:

[dbz400]

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?

[dbz400]

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:

[dbz400]

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: #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.

[dbz400]

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

[dbz400]

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.

[dbz400]

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 #2286

[dbz400]

@solarmystic . I see. Thanks.

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

[dbz400]

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 0eadfdc .

[TallgeeseHeaven]

@raven02
I should tell you, the latest build you posted in #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.

[dbz400]

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.

[dbz400]

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?

[dbz400]

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.

[dbz400]

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

b039768

Your pull above (#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?

[solarmystic]

@raven02 @unknownbrackets

Heh, that https://github.com/raven02/ppsspp/commit/7f5b87361eeeb917383398b8b167e9ec03304a6d commit in #3640 pull request may have solved the map flickering problem, but it introduced another graphical issue.

0.9.1-578 20f6e4b :-

This did not exist in the previous revision without the commit (0.9.1-576) f5375b7 :-

Temporary solution for this issue is the same like the previous one, resize your window, switch rendering modes, and the problem will go away. Until the next time it happens of course.

Video demonstration of the issue:-
http://www.youtube.com/watch?v=5ou6N0WXAm0&feature=youtu.be
http://www.mediafire.com/?0xarh1bli4jcsc1

[dbz400]

Alright .I just back home and test again .Looks like even though i put back the || entry->invalidHint == -1 in latest source code here now , it still show the above graphical error , can you confrim from your side as well ?

Only comment out the keep framebuffer alive one fixes both issues.

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

[solarmystic]

@raven02

If I put back the || entry->invalidHint == -1 in the latest source code I don't get the above error (blue screen error) for my ATI card. I get the world map flickering error again though, like I would expect, since we reverted the fix.

Same results as in my previous post, just altered the single line like you instructed on latest source code based on the v0.9.1-580-g515874c 515874c master.

Perhaps it's an NVIDIA only thing. Commenting out the keep framebuffer alive commit does fix both issues though.

[dbz400]

@unknownbrackets , any alternative we can try here or it is safe to comment out that keep framebuffer alive at this time being?

[unknownbrackets]

It's strange in the first place, I've been busy lately but I'll have to just list out the framebuffers and textures again and build a story of what the game is trying to do, then figure out how to make PPSSPP sing a long with that story.

-[Unknown]

[dbz400]

Sure @unknownbrackets .

[unknownbrackets]

It's confused because there are multiple framebuffers at the same address. If I switch it to just force the format:

    // Find a matching framebuffer
    VirtualFramebuffer *vfb = 0;
    for (size_t i = 0; i < vfbs_.size(); ++i) {
        VirtualFramebuffer *v = vfbs_[i];
        if (MaskedEqual(v->fb_address, fb_address)) {
            // Let's not be so picky for now. Let's say this is the one.
            vfb = v;
            // Update fb stride in case it changed
            vfb->fb_stride = fb_stride;
            vfb->format = fmt;
            if (v->bufferWidth >= drawing_width && v->bufferHeight >= drawing_height) { 
                v->width = drawing_width;
                v->height = drawing_height;
            } 
            break; 
        } 
    }

It works fine (blur on map, no flicker, dialog is fine.)

-[Unknown]

[dbz400]

That's good .Just tested put back the following one that i previously remove , also works fine.

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

[unknownbrackets]

It may break other games, I didn't really try it. The above reuses buffers (and more importantly, does not resize / embiggen them afaik) used at the same address even with a different format.

-[Unknown]

[dbz400]

Alright. I will try it with other games and report here.

[dbz400]

This one definitely a lot better for games.

It fixes Kurohyou 2, Evangelion Jo and Kingdom Hearts #3237

-Kurohyou 2,
Before

After

-Evangelion Jo

Before

After

-Kingdom Heart
Before

After

[unknownbrackets]

Note that this is only safe when true color is enabled/forced.

-[Unknown]

[dbz400]

I see. Those above screenshots is using TrueColor = True.

BTW, also fixes the Midnight Club 4 .#3578

[unknownbrackets]

Oh, and alternative might be to scan fbCache_ in DetachFramebuffer().

-[Unknown]

[dbz400]

I just tried the new code above but seesm to be not working propertly when compared to previous one.

[dbz400]

FYI. The old code fixes the shadow in the Kingdom Heart as well .

[unknownbrackets]

When you say the new code, you mean deleting the old framebuffer, right? In other words, 69e4b34 works but b56c9e5 doesn't?

-[Unknown]

[dbz400]

Yes , correct . Only 69e4b34 works okay but not b56c9e5

[dbz400]

Just wonder what does it mean ?

        if (v->bufferWidth > drawing_width && v->bufferHeight >= drawing_height) { 
            v->width = drawing_width;
            v->height = drawing_height;
        } 

[dbz400]

As with that ifdef check , Kingdom Heart scene looks like this

Remove the check which is

        v->width = drawing_width;
        v->height = drawing_height;

[unknownbrackets]

This is with the old code right? That's the problem I'm trying to avoid. The framebuffer is not resized.

Probably scanning fbCache_ will help, don't have time now.

-[Unknown]

[dbz400]

Yes , it is with old code.

[dbz400]

May be later we can try the scanning fbCache_ in DetachFramebuffer()

[dbz400]

Unfornaturely , the old code causes some artifact in GOW . Seems to be rendered some garbages.

[unknownbrackets]

Aha. I found a better fix. Testing more, this is likely to fix KH and others.

-[Unknown]