Brooktown High broken graphics (depth related?)

[daniel229]

It only works in software gpu,in openGL,it's black and slow,disable slower effects may help the speed.

openGL

software gpu

frame dump(rename jpg to rar)

[unknownbrackets]

Does #7515 improve this at all?

-[Unknown]

[daniel229]

No, it doesn't.

GE debugger

more tabs
https://gist.github.com/daniel229/e257c5e0426b32feb74b

[unknownbrackets]

Seems like a render-to-texture CLUT, possibly.

Texture = 04154000 (and is black, hmm...)
CLUT is 32-bit, seems to take R (0xFF mask.)
Dunno what format 04154000 is though.

If you set a breakpoint on 04154000, does it hit? Does it ever draw anything to 00154000?

-[UNknown]

[daniel229]

It does not hit 04154000,and don't see draw anything to 00154000.
Even the texture is not black,it still draw black thing.

more tabs
https://gist.github.com/daniel229/a36932318f45f6d0b44a

[unknownbrackets]

That texture looks like it's mostly transparent.

Alpha test: pass if (a & ff) >= (08 & ff)
Alpha blend mode: add: src.a, 1.0 - src.a
Depth test: pass if src <= dst

What if, when it's right there, you disable the depth test (go to the Flags tab, and double click depth test.) If you Step Draw, does it draw? If not, can you try the same for alpha test and blend? That should tell us which test it's caused by.

But, that doesn't look like a rendered texture, so not sure why alpha would be wrong...

-[Unknown]

[daniel229]

depth test off it draws that thing.

[unknownbrackets]

If you set a breakpoint on the depth buffer at 0x04110000, does it write anything?

If not, I wonder if it's depth sharing or just some bugs to do with depth handling.

-[Unknown]

[daniel229]

it does not hit 0x04110000

[daniel229]

Seems nothing draw to 0x04154000

more tabs
https://gist.github.com/daniel229/cc8b29fac0e80398e451

JPCSP seems always good on the game even on the version 4 years ago 0.6-1980

[sum2012]

v1.2.2-969-g883b659 still same problem

[sum2012]

v1.3-540-g29739c8 still same problem

[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]

[sum2012]

Not sure I do right or not
https://drive.google.com/file/d/1CPuEox3Qc6kHIJTSjjSQiNOdMAmx1wch/view?usp=sharing

Also I forget to mention that the screen is slow. fps 3/60
v1.6.3-419-gd23d58c40 debug log: https://drive.google.com/file/d/1dGe2rGFWIL_3VDZNp245SPQMBN0A0J20/view?usp=sharing

[unknownbrackets]

Thanks. Turns out this is a depth sharing issue. Bah.

It binds 0x00154000, clears depth, and then switches to the real framebuffer. BlitFramebufferDepth() doesn't happen, because the clear is the last thing in a frame, so NotifyRenderFramebufferSwitched is never even called with the old framebuf.

There's also a bunch of unnecessary depth copies here.

Oh, also, it's doing that small square rendering from framebuffer thing also.

-[Unknown]

[sum2012]

update dump file on v1.9.3-743-gbf6357a53
https://drive.google.com/file/d/1sXoVabVGQikOxcvDe9VkOv3P4HsD4VGo/view?usp=sharing

[Panderner]

Same happens in latest build

OpenGL:

Vulkan

[Panderner]

GPU usage hits 100% usage when using Direct3D 9 and Direct3D 11 unlike OpenGL and Vulkan:

[Panderner]

Software Rendering screenshot:

Here's a GE dump recorded on software rendering:
ULUS10257.zip

[Panderner]

But the game crashed during introduction quiz.

Crash log here:

Brooktown    E[JIT]: x86\CompBranch.cpp:684 Branch in JumpReg delay slot at 088d2a44 in block starting at 088d2a3c

[unknownbrackets]

GPU usage hits 100% usage when using Direct3D 9 and Direct3D 11 unlike OpenGL and Vulkan:

Yeah, as I recall this is doing that evil palette ramp thing.

I wonder if there's some specific behavior we need to emulate for this branch in a branch delay slot. Must be a compiler bug or something handcoded? That or it's garbage...

-[Unknown]

[unknownbrackets]

Apparently this is a likely branch (beql) with a jr ra inside it. I wrote a hardware test and fixed the interpreter to behave correctly in this case: #15952

Can you check if the artifact from that build avoids the crash in interpreter for the quiz? The branching behavior with a delay slot is still not handled in IR interpreter or jit.

-[Unknown]

[sum2012]

I do not enable fast memory so that it does not crash,just the screen don't response.
v1.13.1-710-g65c016d15 (after pr) is fixed with interpreter
edit : fix version

[unknownbrackets]

Thanks for confirming, #15957 should fix that in jit and IR as well.

-[Unknown]

[sum2012]

v1.13.1-745-ga42807ea6-windows-amd64 jit and IR fixed

[sum2012]

Update frame dump to v1.14.4-297-g99d992a00
ULUS10257-opengl.zip
ULUS10257-softgpu.zip

[Yuuuufa]

Were you guys able to fix the rom at the end?
Please post it here if it is the case.

[sum2012]

@Yuuuufa Use software rendering with frameskip