Yu-Gi-Oh! GX Tag Force Card summoning (card cut-off / cropped)

[metaasza]

When the card is summoned, its appeared that the head of the card is disappear as in #5470 and the duel point table's text is also missing. I was trying to find the solution already but it seems that I cannot find anything that can solve my problem. Sorry if this post was annoying but I don't know how to do as I am a very newbie.

Thank you

I use Samsung Galaxy S III (GT-i9300)
http://www.gsmarena.com/samsung_i9300_galaxy_s_iii-4238.php

latest build PPSSPP v0.9.9.1-1042-gff68e32

[D8174]

I'm curious why you closed this. For me these issues still exist. The missing text one is especially annoying.

[hrydgard]

Do the errors happen only on Android or also on Windows, for example?

[D8174]

They happen on Windows too.

[DragonNeos]

@hrydgard @syrobee The text doesn't show up on the Duel Bonus and New High Score Bonus screen if you use the fonts that come with PPSSPP. If you use the PSP fonts, the text does show up on those screens on Windows (don't have an Android to test with).

[D8174]

@DragonNeos Oh okay, I didn't know that was a thing. Thanks.

[lordemort]

i also got some problem here, for Yu Gi Oh Tag Force
when i save the game via the map it stuck in "checking memory card..."
others,like sound,animation, is still working normally, only the checking memory card screen just stuck there,also when i want to change my deck name it didn't show the alphabet keyboard on gray-background,so i just press change deck name and nothing happened

and also here is the log,
if i save via map,it stopped in "...wrong dialog type"
http://pastebin.com/0LHfj30b -->save via map
http://pastebin.com/gb31gANS -->deck name

sorry for the long post and my english
i don't know how to fix it
Thank you

i'm using ppsspp for windows

[daniel229]

A little change since #8130 ,the card is moving to the top,not in the centre.

before

[unknownbrackets]

Okay. Now that really explains why the top is cut off, right? It's right up against the edge. So clearly something about being flipped was happening wrong here - maybe it still is positioning it wrong.

In Core/Reporting.cpp, find:

    bool ShouldLogOnce(const char *identifier)
    {
        // True if it wasn't there already -> so yes, log.
        return logOnceUsed.insert(identifier).second;
    }

Change to:

    bool ShouldLogOnce(const char *identifier) {
        return true;
    }

Also please change this:

    bool IsEnabled()
    {
        if (g_Config.sReportHost.empty() || (!currentSupported && PSP_IsInited()))
            return false;
        // Disabled by default for now.
        if (g_Config.sReportHost.compare("default") == 0)
            return false;
        return true;
    }

To:

    bool IsEnabled() {
        return false;
    }

To avoid spamming it, heh, with that change.

Then, what does it log as far as any transfers during this?

-[Unknown]

[daniel229]

just spamming this

38:38:664 user_main    W[G3D]: GLES\StateMapping.cpp:908 Unsupported depth range test - depth range: 50000.000000-10000.000000, test: 0.152590-0.76295
1

[unknownbrackets]

Oh, sorry, well in that case try changing all the WARN_LOG_REPORT_ONCE and WARN_LOG_ONCE in GPU/Common/FramebufferCommon.cpp to just WARN_LOG. You'll have to remove the first argument too, like before.

-[Unknown]

[daniel229]

Still don't see it log other things
the log.
https://gist.github.com/daniel229/ef9d884f5dbf7abaa9ff

[unknownbrackets]

Relevant lines:

49:48:880 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:417 Creating FBO for 00088000 : 480 x 272 x 3
49:48:880 user_main    W[G3D]: Common\FramebufferCommon.cpp:608 Memcpy fbo upload 04488000 -> 04088000

49:48:989 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:417 Creating FBO for 00160000 : 128 x 272 x 3
49:48:989 user_main    W[G3D]: Common\FramebufferCommon.cpp:608 Memcpy fbo upload 04560000 -> 04160000
49:48:989 user_main    W[SCEGE]: Common\FramebufferCommon.cpp:453 FBO reusing depthbuffer, 00160000/00110000 and 00088000/00110000

49:49:055 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:417 Creating FBO for 00000000 : 480 x 272 x 3
49:49:056 user_main    W[G3D]: Common\FramebufferCommon.cpp:608 Memcpy fbo upload 04400000 -> 04000000

I hope it's not an effect from before that save state. Does disabling the block transfer setting have any effect? If it doesn't, I guess it must be render-to-texture.

There are three textures after all so that does seem likely. I guess the 128 x 272 x 3 one is likely being used for the card.

-[Unknown]

[daniel229]

Those lines is from loading savestate.Disabling the block transfer not affect anything.

[daniel229]

Going back to centre since #8168

[hrydgard]

If it's still cut off, I don't think it's a viewport problem, more likely some framebuffer size problem or similar. But good that it's back.

[Anuskuss]

I'm having this exact same problem with Yu-Gi-Oh! GX Tag Force 2.

Reproduce:
Just duel someone. Seriously, this bug happens in every duel. The quickest way would be to start a duel from the main menu and wait for a card to have an effect. In my example I'm (special) summoning a monster with Premature Burial, and then you can see the monster popping in the middle of the screen.
Unfortunately I'm too dumb (or my PC is too bad) to use gDEBugger, so I can only provide screenshots.

Frame 1

Frame 2

Frame 3

Frame 4

As you can see in Frame 1, to card is rendered correctly. But when the animation continues, you can clearly see that there's an area, which "blocks" the card.

I'm not a programmer, but it seems that the cards of my opponent are on a "higher layer" than the card in the middle, so it's blocking the middle card.

[Anuskuss]

@hrydgard Well, I couldn't find anything special in the GE Debugger, but I think I have an idea. The card's texture is stored squarely (obviously) and then later gets transformed in it's card state.

Maybe PPSSPP assumes it has to be output squarely, so it ignores the top of the card - if that makes any sense.

[Anuskuss]

Hey @hrydgard it seems like you're on fire right now and I want to know if you can put some of your time to fix this before 1.4. If you want me to test/do something, just tell me 😃

Edit: Just wanted to add that the latest jpcsp (rb4d22e0) also has this problem.

[Anuskuss]

Still an issue. Can you help me help you?

[unknownbrackets]

Could you try exporting a GE debugger dump on PC?

To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.

After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.

-[Unknown]

[Anuskuss]

Take a look at this clip:

When my opponent first sets the card, it is cut-off at the top. But when they activate its effect, everything looks in order. I know it's not the same animation, but it might give you a clue.

Bad card
First dump

Good card
Second dump

[unknownbrackets]

Thanks for the dump, it was very helpful. This is an issue with viewport clipping.

Note to self: texture at 0x08872640 in this dump.

What happens is, it uses these viewport parameters:

• Center at 2122, 2111 (z=30000)
• Scale more normal: 240, -136 (z=-20000)
• Offset is normal: 1808x1912

This ultimately causes us to set the viewport for Y to (x, 63) - (x, 335)

The region it's drawing to is (x, 45) - (x, 199)

Because (-1, 1) in the shader output is mapped to (63, 335) by viewport, all pixels above y=63 are clipped. However, the PSP clips based on region (I think) or just the 4096 box, not based on the viewport params. We've basically seen this issue with depth, but it's less common with X and Y.

We would need to map the viewport to the full region, and then handle the viewport scale/centering within the matrix transform. I think that's the best solution to this, and it's basically the same idea as "accurate depth".

The software renderer is also clipping incorrectly for the same basic reason afaict...

-[Unknown]

[epprom]

Game: Yu-Gi-Oh! GX Tag Force
Version : PPSSPP v1.7.4 (X64)
Game ID : ULES-00600
OS : Windows 10 x64
Direct3D11

About card cut-off / cropped. I have the same issue.
ULES00600_0001.zip

Update: (19/03/2019)

• PPSSPP v1.8 (X64) (Same issue)

[ghost]

Issue still present

PPSSPP v1.9.3-647 build
Android Platform

[hrydgard]

As @unknownbrackets pointed out, it might be that #13251 fixed this - needs testing.

[Anuskuss]

I can't believe my eyes, after all those years it's finally FIXED! Great job team, another long-standing issue gone.
I've tested it in all backends and all were fixed except Direct3D 11, which got worse, but hey, the game has reached 100% compatibility now 👍

[Panderner]

@Anuskuss could you screenshot it on Direct3D 11?

[hrydgard]

I think I got it, committed a fix to master.

[Anuskuss]

Confirmed! Issue can be closed.

[unknownbrackets]

I still don't really understand fully the interaction between scissor and region here, and if one of them should apply over the other. Glad it's fixed.

-[Unknown]

[hrydgard]

@unknownbrackets Here's my understanding:

The viewport is really just a scale and an offset, even on PC GPUs (the center and scale are computed by the driver from the viewport rectangle you pass in). However, in the traditional GL model, clipping to the frustrum is specified to happen, which is tight enough that no triangles (or post-clip more-sided polygons) extend beyond the viewport rectangle when rasterized.

Now, correct 3D triangle clipping is kind of expensive, so the "guardband" was invented. This simply extends the coordinate system for triangle rasterization outwards, allowing the GPU to actually do clipping work only when vertices are far away (or behind the camera, in which case you really do need to clip). Thus, to simulate the old behavior of the viewport acting as a scissor, drivers simply use the minimum of the viewport rectangle and the scissor to set the scissor, resulting in identical behavior but a lot less clipping work. There have been driver bugs where this didn't happen, resulting in rendering outside the viewport but inside the scissor, see "Viewports do not clip at clip-space boundaries" on https://community.arm.com/developer/tools-software/graphics/f/discussions/9344/vulkan-driver-issues---workaround-collection-thread

On the PSP, no real triangle clipping on the sides is performed by the hardware. The guardband is the 4096x4096 coordinate system that we all know and love, and instead of clipping, triangles are simply discarded outside. Since no 3D clipping is performed, the viewport rectangle (which never exists here) doesn't apply, so to simulate it correctly on PC APIs, we need to extend the viewport rectangle out to the scissor, adjusting the projection appropriately.

[unknownbrackets]

Yeah, that makes sense. I just don't really understand what the "region" is...

Also, I do think it may do "real" clipping when clamping depth. Which I still think is weird. I wonder if region or scissor interacts with that in ways I haven't tested...

-[Unknown]

[hrydgard]

Yeah the "region" is a bit of a mystery to me too. Could it be what screen rectangle GE_CMD_BOUNDINGBOX checks boxes against maybe? Or something with spline culling?

And indeed it does seem to do real clipping in Z. At least having a single clip plane limits the number of corners the output polygon can have to 4, which might simplify the hardware...

[ghost]

There's still cut on software rendering.

[hrydgard]

Yeah we still do clipping against all six planes in the software renderer. Should probably remove all but the front and back planes.