Repository navigation
Tokimeki Memorial 4 graphic issue. #6379
Description
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
Activity
unknownbrackets commentedon Jun 20, 2014
Annoying. It looks like the game is rendering to a y offset within a framebuffer.
-[Unknown]
daniel229 commentedon Jul 28, 2014
Just a black box since #6513
rysss commentedon Oct 8, 2014
can't play with big black box in the middle.
unknownbrackets commentedon Jan 7, 2015
Does #7289 fix this or are the arms still broken, just black box resolved?
-[Unknown]
daniel229 commentedon Jan 7, 2015
Arms still broken
rysss commentedon Jan 7, 2015
same. tested for windows x64
On Jan 7, 2015 12:14 PM, "daniel229" notifications@github.com wrote:
rysss commentedon Jan 7, 2015
screenshot showing black bar on top arms
On Jan 7, 2015 12:19 PM, "rendy ys" free4logix@gmail.com wrote:
daniel229 commentedon Jan 15, 2015
read framebuffered to memory seems draw the arm correct from GEdebugger
normal buffered rendering
read framebuffered to memory
daniel229 commentedon Jan 15, 2015
Shadow of Memories has the same problem.
unknownbrackets commentedon Mar 1, 2015
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 commentedon Nov 3, 2015
A little change,the lower part is cut out since #8130
unknownbrackets commentedon Nov 3, 2015
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->heightaway 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 commentedon Nov 4, 2015
go back to the usual broken look since #8168
benderscruffy01 commentedon Apr 2, 2019
v1.8.0-88-g24cfad87d
still happens
DUMP.ZIP
unknownbrackets commentedon Apr 7, 2019
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]
10 remaining items
hrydgard commentedon Aug 28, 2023
Just for the record,
[AllowLargeFBTextureOffsets]which fixed a similar framebuffer stitching issue in Juiced 2 (#7295) doesn't help here.Improve disc ID detection for old frame dumps.
hrydgard commentedon Dec 30, 2023
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.
Allow merging framebuffers vertically like the old Juiced 2 fix.
hrydgard commentedon Dec 30, 2023
Please test new builds with that commit, and re-open if there are still issues.
hrydgard commentedon Sep 30, 2026
The problem in the second screenshot has returned.
Size the render target viewport from the whole buffer, not the guesse…
hrydgard commentedon Oct 11, 2026
This should be fixed again.