ppsspp
ppsspp copied to clipboard
hrydgard
Evangelion Jo : Missing menu text
Just for record. Looks like it is sceFont issue .
HLE\sceFont.cpp:877 sceFontGetCharGlyphImage_Clip(09f094dc, 65326, 09ffe710, 0, 0, 254, 30) HLE\sceFont.cpp:877 sceFontGetCharGlyphImage_Clip(09f094dc, 65332, 09ffe710, 0, 0, 254, 30) HLE\sceFont.cpp:877 sceFontGetCharGlyphImage_Clip(09f094dc, 65321, 09ffe710, 0, 0, 254, 30) HLE\sceFont.cpp:877 sceFontGetCharGlyphImage_Clip(09f094dc, 65326, 09ffe710, 0, 0, 254, 30) HLE\sceFont.cpp:877 sceFontGetCharGlyphImage_Clip(09f094dc, 65333, 09ffe710, 0, 0, 254, 30) HLE\sceFont.cpp:877 sceFontGetCharGlyphImage_Clip(09f094dc, 65317, 09ffe710, 0, 0, 254, 30)
This is from real PSP .Looks like JPCSP also cannot render this text completely.
Has this improved at all? There were some improvements to sceFont.
I wonder if it's similar to the Fieldrunners issue.
-[Unknown]
The fact that you're getting some white garbage there probably means that sceFont is actually drawing text somewhere but we're not texture mapping it correctly. Maybe it's a vertical texture with a very small stride that we're mishandling somehow? Don't really have any better ideas...
Interesting. So I guess it's rendering the text from a temporary buffer or something?
-[Unknown]
Okay, if it's correct in softgpu it's definitely not an sceFont bug at least...
Does this look any better in the latest git build with simulate block transfers?
-[Unknown]
Does it ever render the text into a temporary buffer? Maybe it's offset beyond max subarea...
Which FBOs are in the log under "Creating FBO"?
-[Unknown]
Tested with latest build. Fonts are still missing:
If I load a savestate with softgpu fonts are gone too, but If I load the game in softgpu from the beginning, fonts appears but in wrong way (same word in all parts):
Other than that game looks fine ingame:
Interesting. So that means we are probably missing some sort of render-to-texture effect here.
-[Unknown]
Still missing text
39:29:591 user_main I[SCEGE]: Common\FramebufferCommon.cpp:412 Creating FBO for 001fe7c0 : 156 x 12 x 0
39:29:593 user_main I[SCEGE]: Common\FramebufferCommon.cpp:412 Creating FBO for 001fcf00 : 156 x 12 x 0
39:29:594 user_main I[SCEGE]: Common\FramebufferCommon.cpp:412 Creating FBO for 001fb640 : 156 x 12 x 0
39:29:607 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1896 Decimating FBO for 001fe7c0 (156 x 12 x 0), age 6
39:29:608 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1896 Decimating FBO for 001fcf00 (156 x 12 x 0), age 6
39:29:609 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1896 Decimating FBO for 001fb640 (156 x 12 x 0), age 6
if I comment out these,it shows up,still not correct.
/*if (vfb != displayFramebuf_ && vfb != prevDisplayFramebuf_ && vfb != prevPrevDisplayFramebuf_) {
if (age > FBO_OLD_AGE) {
INFO_LOG(SCEGE, "Decimating FBO for %08x (%i x %i x %i), age %i", vfb->fb_address, vfb->width, vfb->height, vfb->format, age);
DestroyFramebuf(vfb);
vfbs_.erase(vfbs_.begin() + i--);
}
}*/
GE debugger
https://gist.github.com/daniel229/58998ba723dc08834dac
Break on 0x041FE7C0,got this function. https://cloud.githubusercontent.com/assets/3481559/12633684/920ae3b0-c5ae-11e5-8080-fa87a225b250.png
Interesting, this uses memcpy and memset. Do the changes in #8359 help?
-[Unknown]
v1.2.2-288-g9a11cfb log: https://gist.github.com/sum2012/42bfe40c7e65645bdf715521fd751d04
Maybe we need imp SysMemUserForUser_D8DE5C1E() ?
Perhaps. It seems that our implementation was from Jpcsp, and they both just return 0. It still doesn't work in Jpcsp, right?
Given it's in sysmem, maybe SysMemUserForUser_D8DE5C1E is an allocation function. Can you change:
ERROR_LOG(SCEKERNEL,"UNIMPL SysMemUserForUser_D8DE5C1E()");
To:
ERROR_LOG(SCEKERNEL,"UNIMPL SysMemUserForUser_D8DE5C1E(%08x, %08x, %08x, %08x, %08x, %08x)", PARAM(0), PARAM(1), PARAM(2), PARAM(3), PARAM(4), PARAM(5));
Wondering what params it uses.
According to Google, some people claim this function is sceKernelSafetyCheck0. If so, maybe it's unlikely it would impact functionality... not sure what it does or is meant to do.
Is it possible to log that func via JpcspTrace?
-[Unknown]
Modify ppsspp log: https://gist.github.com/sum2012/01991fc9a5a79d6e654af86f58034401
edit: update JPCSPTrace log: https://gist.github.com/sum2012/207d04e4271a7a2bfff74801d9852445
JPCSP render wrong font
Oh, sorry, just read the history again - this is definitely render-to-texture related somehow, and probably also impacted by expiring FBOs too early. Hmm.
-[Unknown]
Apparently the JPCSP issue is a flushing issue (which we probably also would share, if we were even rendering properly.)
It renders the labels to a temporary texture, and sets a stall address. It then updates the source texture it's using to render the labels, and switches to the next render target for the next label.
The problem is, when drawing is deferred until state change, the game changing texture RAM doesn't cause flushing. So it draws the next text (with confused UVs) to the target. That's why "OPTION" and "OPTION" twice above, and "CONTINUE" looks funky (since it wants to write "NEW GAME".)
-[Unknown]
Ugh, that's such a terrible misuse of hardware :) Ruins parallelism between the CPU and GPU.
So to fix this, we simply need to flush our collected vertices on every stall. Pretty sure that will slow down some games (especially games with large textures, causing more hashing work), though the really high-demanding games usually are smarter than stalling that often so hopefully wouldn't be affected too badly.
Maybe a compat bool....
Tested that a bit and unfortunately flushing in UpdateStall didn't helped much since nothing shows unless Read framebuffers to memory is used or another frame download hack get's added(with different address per each menu option and some menus have lots more options, largest menu I saw had like 10 positions with fb_address starting from 0x001F3A80, up to 0x001FE7C0).
Using just a new frame download hack it would look alike jpcsp:
with addition of flush on UpdateStall, while better, it's still messed up:
The messup is also slightly different for different menu's like here seen right after loading game:
which should look like:
Last field as can be seen always ends up outdated ~ taken from previous menu / or empty in case it's first menu. Leaving and re-entering makes that field show correctly since previous menu is then same as current.
Evil game.:]
