dai-2-ji super robot taisen z saisei-hen graphical problem (Bezier issue?)

[daniel229]

It's always happening.

savestate(rename jpg to 7z)
after loading the savestate press circle button.

PPSSPP

PSP

GE debugger

more tabs
https://gist.github.com/daniel229/913e8052f26d2814d7ec

[daniel229]

Spline/Bezier curves quality Medium seems work fine. still a little green thing in the middle.

Low quality is more like the one high quality.

[unknownbrackets]

The texture is a render-to-texture, and it looks like it's mostly/fully transparent. It's 8888 though, so I suppose #7509 won't likely help here...

Anyway, since it's modulate, it's weird that alpha is becoming anything but zero (unless it's not actually 0, just close, in the texture.) It is using standard alpha blending, no logic ops or anything either.

So, I guess this may be somehow the reverse of the FF4 save bug: we're accumulating too much alpha?

-[Unknown]

[daniel229]

#7509 won't help.

[unknownbrackets]

So, here in GPU/Common/SplineCommon.cpp:

            if (origVertType & GE_VTYPE_COL_MASK) {
                patch.sampleColor(u, v, vert.color);
            } else {
                memcpy(vert.color, patch.points[0]->color, 4);
            }

If you add after:

vert.color[3] = 0;

Does it fix/affect it? The control points do have colors...

-[Unknown]

[daniel229]

Bezier effect is missing.

[unknownbrackets]

Okay. What if you change it from 0 to like 0x80 or 0x40?

-[Unknown]

[daniel229]

0x80 get a little effect.

0x40 even smaller

[unknownbrackets]

Interesting, but none of them have any of the blue. What if you make it 0xC0 or 0xE0?

-[Unknown]

[daniel229]

0xC0 or 0xE0 seems better.
0xC0

0xE0

[unknownbrackets]

Still no blue. It's just a color, is it blue at 0xFF? Or 0xF7? When does the blue start?

-[Unknown]

[daniel229]

It's hard to tell at which start
0xFF

0xFC

0xF7

[unknownbrackets]

Okay, well, it seems to me like C0 or E0 is more correct looking anyway. So sounds like we are getting some of the points' alpha wrong?

-[Unknown]

[daniel229]

A0 looks pretty match.

PSP

[unknownbrackets]

So, then, if you log it instead of changing it, what values does it have?

-[Unknown]

[daniel229]

use many values
https://gist.githubusercontent.com/daniel229/273c3b62b526e88f2592/raw/srwz%20bezier

[unknownbrackets]

It probably won't, but this is something I messed with a little and haven't really tested properly:
https://github.com/hrydgard/ppsspp/compare/hrydgard:master...unknownbrackets:bezier-minor?expand=1

Does that make any impact? It might retain better precision, but probably not much.

I wonder if the issue is that bilinear is not actually good enough?

-[Unknown]

[daniel229]

Seems not change anything

[daniel229]

So the 0xFF make the blue thing,and other value make the effect stronger than the one on PSP.

[hrydgard]

Yeah, it could be that we have to spline-interpolate the colors as well .. I don't know if the PSP does that or if it does them with bilinear interpolation. If so, that's annoying of a game to rely on it and not just look a tiny bit worse :P

[unknownbrackets]

When you say spline interpolate, do you mean like with positions - would that be a "4d" bernstein?

Maybe we only do it for "high" quality?

-[Unknown]

[hrydgard]

Well, 4x 2d bernsteins, one for each color component.

[unknownbrackets]

Hmm, it'd still be of degree 3, right? Meaning it'd still go from 0 to tess_u/tess_v. Sorry I don't really understand this bernstein stuff well.

It seems like I'd pass in a Vec4f of the color, with the same 16 points, but their colors. No need for derivatives, since I'm not computing a normal. Or do you mean a bernstein between the control points, rather than lerp?

If it's true that colors are spline-interpolated, I wonder if UVs could be too. Of course could be neither.

I wonder if there's a sane way for me to construct a test that would tell me... hmm.

-[Unknown]

[hrydgard]

Same degree, just one more component (color is RGBA, position is XYZ). And yeah, most likely the UVs are too.

I think just drawing a 4x4 patch with a high tesselation factor, and where the control points are positioned a bit irregularly and colored differently, would do as a test - image compares should make a difference visible.

[daniel229]

Since #8259 ,now is black,and there is a frame is not correct.

the video rename jpg to mp4.

also a video before that pr

[unknownbrackets]

If you comment out this part, the black goes away?

https://github.com/hrydgard/ppsspp/pull/8259/files#diff-5b998bdeb6be184246bb712047ce81f7R540

If so, can you revert that, and then change this part here:
https://github.com/hrydgard/ppsspp/pull/8259/files#diff-29313f9f6ed28d0e24e6dac4e0db8933R1378

                glCopyImageSubData(
                    fbo_get_color_texture(src->fbo), GL_TEXTURE_2D, 0, srcX1, srcY1, 0,
                    fbo_get_color_texture(dst->fbo), GL_TEXTURE_2D, 0, dstX1, dstY1, 0,
                    dstX2 - dstX1, dstY2 - dstY1, 1);
                return;

To:

                glGetError();
                NOTICE_LOG(HLE, "src %d,%d -> dst %d,%d  %dx%d", srcX1, srcY1, dstX1, dstY1, dstX2 - dstX1, dstY2 - dstY1);
                glCopyImageSubData(
                    fbo_get_color_texture(src->fbo), GL_TEXTURE_2D, 0, srcX1, srcY1, 0,
                    fbo_get_color_texture(dst->fbo), GL_TEXTURE_2D, 0, dstX1, dstY1, 0,
                    dstX2 - dstX1, dstY2 - dstY1, 1);
                NOTICE_LOG(HLE, "glCopyImageSubData: %08x", glGetError());
                return;

I'm assuming the black means the copy is failing for some reason.

-[Unknown]

[unknownbrackets]

Oh, maybe try changing:

if (dstX2 - dstX1 == srcX2 - srcX1 && dstY2 - dstY1 == srcY2 - srcY1) {

To:

if (dstX2 - dstX1 == srcX2 - srcX1 && dstY2 - dstY1 == srcY2 - srcY1 && dst != src) {

Although, I thought I accounted for that already somewhere...

-[Unknown]

[daniel229]

Revert that part help.but I don't get any NOTICE_LOG in game.

Restore the revert,and then follow the change above does not help it.

[unknownbrackets]

How about around the glCopyImageSubDataNV( one instead?

-[Unknown]

[daniel229]

Still don't get any NOTICE_LOG

[daniel229]

I think you mean not commet out https://github.com/hrydgard/ppsspp/pull/8259/files#diff-5b998bdeb6be184246bb712047ce81f7R540
then I get this

20:45:230 user_main    N[HLE]: GLES\Framebuffer.cpp:1391 src 0,0 -> dst 0,0  2048x1088
20:45:230 user_main    N[HLE]: GLES\Framebuffer.cpp:1396 glCopyImageSubData: 00000501

[unknownbrackets]

Ah, yes, sorry for being unclear. Hmm, GL_INVALID_VALUE... this is at 4x, right? Maybe the buffer is correctly 480x272, not 512x272.

Seems like glBlitFramebuffer doesn't range check.

So maybe replace:

        // Only if it's the same size.
        if (dstX2 - dstX1 == srcX2 - srcX1 && dstY2 - dstY1 == srcY2 - srcY1) {

With:

        // Only if it's the same size and inside the bounds.
        bool sameSize = dstX2 - dstX1 == srcX2 - srcX1 && dstY2 - dstY1 == srcY2 - srcY1;
        bool insideBounds = dstX2 <= dst->renderWidth && dstY2 <= dst->renderHeight && srcX2 <= src->renderWidth && srcY2 <= src->renderHeight;
        bool differentTargets = dst->fbo != src->fbo;
        if (sameSize && insideBounds && differentTargets) {

-[Unknown]

[daniel229]

Yeah,that works for it.

[unknownbrackets]

It looks like they are spline interpolated - or, at the very least, trilinear or something.

For example, if I make the control points like this (I'm testing with flat shading, 0 = red, 9 = blue, just approximations):

CNTRL       PSP         PPSSPP
0000        0000        0000
9999   ->   5555   vs   7777
9999        8888        9999
9999        9999        9999

This is with neatly aligned control points in a grid (evenly spaced.) It's more pronounced if only the top left value is red.

By the way, I'm seeing other issues. For example, we should support divisions of 1 or 2, but seem to assume < 4 means 4.

-[Unknown]