Missing background : Romance Of Three Kingdom 9 PK

[dbz400]

This missing background never worked before in any build .Just for record.

[dbz400]

This is the frame dump log

http://pastebin.com/6yGjzVG2

Already tried to disable alpha/color test but seems not helping

[unknownbrackets]

Sometimes you have to hit it more than once, if the game is frameskipping. That log doesn't have any GE commands in it...

-[Unknown]

[dbz400]

@unknownbrackets Arr .yes , hit twice works oka now . Since it is pretty big in size, i cannot put it in pastebin.

(rename it from jpg to zip is ok)

[dbz400]

@unknownbrackets , wondering anything we can try to change and test it out to see if we can fix this black BG .

[unknownbrackets]

Does the hack I posted at the top of #2308 improve it at all?

-[Unknown]

[dbz400]

Unfornaturely not , it didn't help in this black BG .

[dbz400]

@hrydgard / @unknownbrackets , tried to take the follow changes, the background reappears but fonts missing .Any suggestion changes ?

    if (gstate.isModeThrough()) {
        WRITE(p, "  gl_Position = u_proj_through * vec4(a_position.xy, 1.0, 0.0);\n");
    } else {
        WRITE(p, "  gl_Position = u_proj * vec4(a_position.xy, 1.0, 0.0);\n");
    }

[cv47]

WRITE(p, " gl_Position = u_proj_through * vec4(a_position.xy, 1.0, 0.0);\n");

Which game can fix or broke by change this code?

[hrydgard]

@raven02 , that is surely wrong, because in the w coordinate, we stash the fog depth. Multiplying the fog depth with a column of the projection matrix is just nonsense, so what works, works by accident.

@cv47 , that throws away depth information so if that fixes something it's also by accident.

We are probably missing something else when it comes to Z stuff.. for example we don't implement MINZ and MAXZ, I don't really know how they are supposed to work.

[dbz400]

@cv47 , it somehow fix the fog effect in Sword Art Online but i think it works by accident .

BTW, what is your test fix to make both background and fonts show correctly?

@hrydgard , i see. It did break other games :(

[dbz400]

@hrydgard , would it be vertex decoder issue ? i try something else in DEC_FLOAT_3 or comment out memcpy(pos, f, 12);, the background appears .....

    case DEC_FLOAT_3:
        {
            const float *f = (const float *)(data_ + decFmt_.posoff);
            memcpy(pos, f, 12);
            if (isThrough()) {
                // Integer value passed in a float. Wraps and all, required for Monster Hunter.
                pos[2] = (float)((u16)(s32)pos[2]) * (1.0f / 65535.0f);
            } else {
                for (int i = 0; i < 3; i++)
                    pos[i] = f[i] * (1.f / 32767.f);
            }
        }
        break;

[dbz400]

Alright .Just test this out on the upcoming softGPU , it seems to render all correctly and no missing background . Wondering where should we start to compare the code difference ?

[sraphy]

@raven02 I‘m trying to fix this bug, but I get the same problem as you,
may I ask you what did you do to get both background and font show up ?

if (gstate.isModeThrough()) {
WRITE(p, " gl_Position = u_proj_through * vec4(a_position.xyz, 1.0);\n");
}
if (***) {
WRITE(p, " gl_Position = u_proj * vec4(a_position.xyz, 0.0);\n");
}
else {
WRITE(p, " gl_Position = u_proj * vec4(a_position.xyz, 1.0);\n");
}


[unknownbrackets]

@raven02 my suggestion for comparing with the softgpu is to attempt to make the softgpu look like what you see in gles. But, that is not really easy either...

What you want to do is to identify things. It'd be good to identify what vertex types, values, and state it's using when drawing the background, and the same things for the fonts. DEBUG_TEXTURES was my hack to find these things, but we really need to get around to porting/using/creating the GE debugger...

Once you have that, I would try to test different scenarios to see what it's doing, and what's correct.

-[Unknown]

[dbz400]

@unknownbrackets , yep , i'll follow your suggest approach to see if i can find out the difference .

@sraphy , that one with both background and font show up is from softGPU

[dbz400]

I'm playing around then new GE debugger and found out interesting stuff for this game however not too sure what it means

[dbz400]

I have pressed around 30 times that 'Break' button to get that and the missing background showup

[unknownbrackets]

That means it's drawing the background somewhere (e.g. to a different FBO.)

-[Unknown]

[dbz400]

I see. Most likely draw to depth buffer as i seen this log ?

27:04:037 user_main W[SCEGE]: GLES\Framebuffer.cpp:610 FBO sharing existing depthbuffer (unsupported), 00088000/00110000 and 00000000/00110000

[unknownbrackets]

Well, it's possible. I added those warnings to get a feel for where it is possible and where it's not.

-[Unknown]

[dbz400]

I see.

[dbz400]

Further checking on this missing background , it may be related to wrong pos?

[dbz400]

softgpu renders well though .

[dbz400]

Just tested this again with "Vertex arrays enabled when there's no data passed for them"

Still black in background

[daniel229]

if these games have the same issue, both are missing background.Danball Senki W and Gundam AGE.

software rendering looks good.

Danball Senki W

Gundam AGE is still not good in software mode.

[dbz400]

In Gundam AGE, it suppose to have background in your screenshot?

[dbz400]

For Danball Senki W, i think the background is only able to show using framebuffer to memory like 3rd birthday

Framebuffer to memory or softgpu

Buffered rendering

[dbz400]

@daniel229 , looks like it has background .I found it in a youtube

[unknownbrackets]

What does it render to the other? What if you set a breakpoint on 04088000 for size 00088000?

-[Unknown]

[dbz400]

Let me try

[daniel229]

set a breakpoint on 04088000 for size 00088000,it did not catch anything.

[daniel229]

It render to 00000000 and 00088000 in turn frame by frame.

first frame to 00000000
second 00088000
third 00000000
four 00088000
.
.
.
.
.

[daniel229]

Still no change in v1.1.1-215-gd2701d7

[unknownbrackets]

Hrm. If you save state / load state does it still display something?

When loading state, it loads whatever is in RAM behind the framebuffers. That's why it implies to me that it has drawn something to RAM and the framebuffers are just black. But if breakpoints don't trip...

We did fix some missing breakpoint checks, though. Can you double check if they don't trip now? Make sure to set the breakpoints before entering the scene, or else pan the view. It may only redraw when there's a change (possibly...)

-[Unknown]

[daniel229]

save state it still displays the same screen,load state it display a blackscreen then the same bug screen. I set speed to 5%.
From entering to the scene,it's drawing the cloud,and than nothing more than later.

[unknownbrackets]

And no hits on the memory breakpoint either?

Software rendering works right? Maybe @raven02's savestate was from softgpu and that's why it worked for a second. Hmm.

-[Unknown]

[daniel229]

breakpoint which address?

[unknownbrackets]

04000000 with size 0x110000.

-[Unknown]

[daniel229]

Not hit.

[sum2012]

update the log to v1.1.1-340-g01669cb
https://gist.github.com/sum2012/0860d89bb54d08dbd39e
@unknownbrackets yes,it need soft gpu for work

[unknownbrackets]

I've gotten some GE debugger related info on this. Dumping my observations from that data here:

Apparently, the game draws everything fine, until some point when it draws something on the framebuffer with blending. This is when the framebuffer goes black.

This particular draw seems weird. It seems it's drawing lines using rectangles, but:

• Texturing is disabled.
• Vertices include funky UV values.
• There's an extra rectangle (by accident?) with XY 0,0 - 8000,4000.

The last thing is apparently the kicker. By hacking it to avoid this last rectangle, the game seems to draw fine. It's not a block transfer issue at all, then, but instead a clipping one.

On the PSP, per my earlier tests, anything drawn outside the 0,0 - 4096,4096 window coords (translated/scaled via the viewport) gets clipped entirely. Therefore a draw of 8000,4000 should simply be skipped outright. It's accidental and incorrect that it's even drawn.

IMHO, this is a bug in the game, though. Assuming I'm understanding correctly.

-[Unknown]

[unknownbrackets]

I expect this to work now - on all backends - now that #11393 is merged. How's it look now?

-[Unknown]

[sum2012]

v1.6.3-497-gead4946fd Win 7 64 bit
Opengl fixed.
Directx 9 fixed.
Directx 11 fixed.

[unknownbrackets]

Awesome - I'm going to assume Vulkan is fixed too and close this. Thanks for verifying.

-[Unknown]