Tokimeki Memorial 4 graphic issue.

[daniel229]

Look at the arms.

buffered rendering

read framebuffers to memory fixes the problem,but have other problem.

log

GLES\Framebuffer.cpp:973 Creating FBO for 0015e000 : 256 x 272 x 3
GLES\Framebuffer.cpp:1016 FBO reusing depthbuffer, 0015e000/00110000 and 00000000/00110000
GLES\ShaderManager.cpp:139 Linked shader: vs 27 fs 34
GLES\ShaderManager.cpp:139 Linked shader: vs 36 fs 37
GLES\ShaderManager.cpp:139 Linked shader: vs 39 fs 37
GLES\Framebuffer.cpp:973 Creating FBO for 001a2000 : 256 x 240 x 3
GLES\Framebuffer.cpp:1016 FBO reusing depthbuffer, 001a2000/00110000 and 00000000/00110000
GLES\ShaderManager.cpp:139 Linked shader: vs 22 fs 37
GLES\Framebuffer.cpp:973 Creating FBO for 001de000 : 128 x 136 x 3
GLES\Framebuffer.cpp:1016 FBO reusing depthbuffer, 001de000/00110000 and 00000000/00110000
GLES\ShaderManager.cpp:139 Linked shader: vs 27 fs 42
GLES\Framebuffer.cpp:973 Creating FBO for 001f6000 : 32 x 34 x 3
GLES\Framebuffer.cpp:1016 FBO reusing depthbuffer, 001f6000/00110000 and 00000000/00110000
GLES\Framebuffer.cpp:973 Creating FBO for 001f0000 : 64 x 68 x 3
GLES\Framebuffer.cpp:1016 FBO reusing depthbuffer, 001f0000/00110000 and 00000000/00110000
GLES\ShaderManager.cpp:139 Linked shader: vs 27 fs 44
GLES\ShaderManager.cpp:139 Linked shader: vs 22 fs 46
GLES\Framebuffer.cpp:973 Creating FBO for 00154000 : 64 x 32 x 3
GLES\Framebuffer.cpp:1016 FBO reusing depthbuffer, 00154000/00110000 and 00000000/00110000
GLES\Framebuffer.cpp:973 Creating FBO for 00156000 : 128 x 64 x 3
GLES\Framebuffer.cpp:1016 FBO reusing depthbuffer, 00156000/00110000 and 00000000/00110000

Gedebugger
draw upper part of the girl

draw lower part

then

next step

[unknownbrackets]

Annoying. It looks like the game is rendering to a y offset within a framebuffer.

-[Unknown]

[daniel229]

Just a black box since #6513

[rysss]

can't play with big black box in the middle.

[unknownbrackets]

Does #7289 fix this or are the arms still broken, just black box resolved?

-[Unknown]

[daniel229]

Arms still broken

[rysss]

same. tested for windows x64
On Jan 7, 2015 12:14 PM, "daniel229" [email protected] wrote:

Arms still broken

—
Reply to this email directly or view it on GitHub
#6379 (comment).

[rysss]

screenshot showing black bar on top arms
On Jan 7, 2015 12:19 PM, "rendy ys" [email protected] wrote:

same. tested for windows x64
On Jan 7, 2015 12:14 PM, "daniel229" [email protected] wrote:

Arms still broken

—
Reply to this email directly or view it on GitHub
#6379 (comment).

[daniel229]

read framebuffered to memory seems draw the arm correct from GEdebugger
normal buffered rendering

read framebuffered to memory

[daniel229]

Shadow of Memories has the same problem.

[unknownbrackets]

I think the issue in this game is basically that the game renders to two buffers that are each 256x256, and which are right next to each other.

Because it rendered, we use it as a render-to-texture, but we only have the top half of the texture, not the lower half. We'd need to splice the two framebuffers together, or texture from both of them depending on the v coordinate. Or be really smart and break it into two drawcalls.

Another option might be downloading both framebuffers to memory (in order to splice them.) Since we know that the height is > 256, we can be reasonably sure about the height of the first one, but the second one is unsafe and could corrupt important memory.

I've thought before about trying to do all rendering to one big framebuffer that we try to creatively map to correct coordinates, or else use image load/store or something, but all of these are complicated or require GPU features that the devices we support don't have.

-[Unknown]

[daniel229]

A little change,the lower part is cut out since #8130

[unknownbrackets]

I guess that means it's no longer at the edge on that side, so it's not repeating, or something.

It's annoying it even bothers to draw it in two separate render targets.

@hrydgard what do you think? This actually happens - per my memory - in at least one or two other games. In one of them, it's horizontally, because the game renders at a higher resolution (in two parts) and then scales it down.

To detect it, we'd have to see a framebuffer vfb->height away from the first framebuffer. I'm not sure if there's any benefit in allowing n framebuffers where n > 2. We could also cap this by maxSeenV, e.g. if the UV coords don't need to go outside the first framebuffer, just do what we do now.

Then we could just create a temp FBO, and blit the first framebuffer to the top, and blit the second to the bottom. We'd have to do this every frame but it would probably not be too expensive.

This wouldn't lose any visual quality, but at > 1x render res, there might probably be a line between the two textures in some cases.

I think that'd be fine, does it sound like a good approach?

-[Unknown]

[daniel229]

go back to the usual broken look since #8168

[benderscruffy01]

v1.8.0-88-g24cfad87d
still happens
DUMP.ZIP

[unknownbrackets]

Thanks, for the dump. Dump 1 luckily reproduces the issue perfectly.

The correct output (from a PSP):

And it seems software rendering doesn't have this bug (but it's not perfect, the shadow is wrong near top left shoulder):

GLES indeed shows this bug as in the initial report (and also seems to get the shadow wrong):

In this case, it's texturing from Texture L0: 0x0415e000 (256x512), which is render-to-texture. But it was rendered/detected as only a 256x272 texture. We separately handle a draw into 041a2000, but this is actually supposed to be an offset into the original texture.

One way to handle this might be to detect the texture from two framebuffers, and resize the framebuffer larger. It would mean the first frame would end up cut off, but future frames (if the offset draw was properly detected) could draw into the same framebuffer and then work.

-[Unknown]

[unknownbrackets]

Yeah we either need to detect this scenario or stitch the framebuffers together.

-[Unknown]

[IrfanH495]

My Samsung m20 and Sharp sh04H, also had the same issue
Vulkan & OpenGL

[IrfanH495]

vulkan ppsspp v1.13.2-1892-g65d2f9474
when I play the new game the font display looks like this

[IrfanH495]

v1.15.4-121-g27b8d27ef-android
still happens OpenGL & Vulkan.

[unknownbrackets]

A GE frame dump of the font display issue would be helpful.

-[Unknown]

[IrfanH495]

A GE frame dump of the font display issue would be helpful.

-[Unknown]

sorry for the font issue like my comment has been fixed in a later version, at that time other games also experienced it. I forgot to report it sorry 🙏🙏🙏🙏🙏.

[hrydgard]

Just for the record, [AllowLargeFBTextureOffsets] which fixed a similar framebuffer stitching issue in Juiced 2 (#7295) doesn't help here.

[hrydgard]

Nearing the 10-year-anniversary of the issue, I have a fix by expanding the framebuffer and applying a vertical offset, seems to work. Based on the old method for Juiced 2. Will gate behind a compat flag for safety.

[hrydgard]

Please test new builds with that commit, and re-open if there are still issues.