mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-24 21:56:10 +03:00
[GH-ISSUE #3908] Evangelion Jo : Missing menu text #1595
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#1595
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dbz400 on GitHub (Sep 24, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/3908
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)
@dbz400 commented on GitHub (Sep 24, 2013):
This is from real PSP .Looks like JPCSP also cannot render this text completely.
@unknownbrackets commented on GitHub (Nov 27, 2013):
Has this improved at all? There were some improvements to sceFont.
I wonder if it's similar to the Fieldrunners issue.
-[Unknown]
@dbz400 commented on GitHub (Nov 27, 2013):
Not yet improved unfornaturely.
@dbz400 commented on GitHub (Dec 15, 2013):
@dbz400 commented on GitHub (Dec 15, 2013):
Softgpu bit better but still some garbages
@hrydgard commented on GitHub (Dec 15, 2013):
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...
@unknownbrackets commented on GitHub (Jan 19, 2014):
How does the softgpu look these days?
-[Unknown]
@dbz400 commented on GitHub (Jan 19, 2014):
I tested using 0.9.6-474 , it renders all correct in softgpu
@dbz400 commented on GitHub (Jan 19, 2014):
Please ignore my previous post .Softgpu renders those text all correct now.
@unknownbrackets commented on GitHub (Jan 19, 2014):
Interesting. So I guess it's rendering the text from a temporary buffer or something?
-[Unknown]
@hrydgard commented on GitHub (Jan 19, 2014):
Okay, if it's correct in softgpu it's definitely not an sceFont bug at least...
@unknownbrackets commented on GitHub (Jun 9, 2014):
Does this look any better in the latest git build with simulate block transfers?
-[Unknown]
@dbz400 commented on GitHub (Jun 9, 2014):
It is the same as previously.
@unknownbrackets commented on GitHub (Jun 9, 2014):
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]
@ppmeis commented on GitHub (Jul 15, 2014):
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:
@ppmeis commented on GitHub (Jul 15, 2014):
I notice in Frame Buffer to CPU/GPU looks like softgpu:
@unknownbrackets commented on GitHub (Jul 15, 2014):
Interesting. So that means we are probably missing some sort of render-to-texture effect here.
-[Unknown]
@daniel229 commented on GitHub (Jan 28, 2016):
Still missing text
if I comment out these,it shows up,still not correct.
GE debugger
https://gist.github.com/daniel229/58998ba723dc08834dac
@daniel229 commented on GitHub (Jan 28, 2016):
Break on 0x041FE7C0,got this function.
https://cloud.githubusercontent.com/assets/3481559/12633684/920ae3b0-c5ae-11e5-8080-fa87a225b250.png
@unknownbrackets commented on GitHub (Jan 28, 2016):
Interesting, this uses memcpy and memset. Do the changes in #8359 help?
-[Unknown]
@daniel229 commented on GitHub (Jan 28, 2016):
No,it deosn't.
@daniel229 commented on GitHub (Jan 28, 2016):
Loading savestate from softgpu,look good.
@sum2012 commented on GitHub (Apr 10, 2016):
v1.2.2-288-g9a11cfb still missing text
@sum2012 commented on GitHub (Apr 10, 2016):
v1.2.2-288-g9a11cfb log:
https://gist.github.com/sum2012/42bfe40c7e65645bdf715521fd751d04
Maybe we need imp SysMemUserForUser_D8DE5C1E() ?
@unknownbrackets commented on GitHub (Apr 10, 2016):
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:
To:
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]
@sum2012 commented on GitHub (Apr 10, 2016):
Modify ppsspp log:
https://gist.github.com/sum2012/01991fc9a5a79d6e654af86f58034401
edit: update JPCSPTrace log:
https://gist.github.com/sum2012/207d04e4271a7a2bfff74801d9852445
JPCSP render wrong font
@unknownbrackets commented on GitHub (Apr 10, 2016):
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]
@unknownbrackets commented on GitHub (May 14, 2017):
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]
@hrydgard commented on GitHub (May 15, 2017):
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....
@LunaMoo commented on GitHub (May 15, 2017):
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.:]
@unknownbrackets commented on GitHub (May 17, 2017):
Hm. I don't think UpdateStall is the right place.
Basically the "stall" process works like this (on a real PSP):
So flushing at UpdateStall is too late - that's when the game has already written the new data. Flushing needs to be done when PPSSPP hits the stall and pauses.
Note: PPSSPP (without multithreading) pauses the CPU until rendering is done (i.e. it's never possible to catch it before it hits B.) With multithreading, it does more like the above - but the timing is not consistent, and doesn't at all match a real PSP.
-[Unknown]
@LunaMoo commented on GitHub (May 17, 2017):
Thanks for that explanation - I set it to flush earlier in InterpretList in place it sets GPUSTATE_STALL now and combined with force download hack most of the menu works completely fine:
However the last entry still has same problem, shows only outdated texture from previous menu:]. Might be a different problem?
Edit: Seems that force download hack I made based on the previous one is not enough, or missing some address, since it does show with read to memory. ~ going to investigate further.
Edit2: Must be the address as removing the fb_address check from the hack makes it work, however I had the addresses for all those textures, hmm maybe it's missing for those "temporary textures".
Was able to make the last entry work adding 0x0 address to force download hack:
the range includes 10 different entries, so if any menu has more(I couldn't find such) it might still be missing, but those are always same in all menus, so it seems safe. With added fb_address 0 however, it's used for everything and will have same problems as read to memory, in fact it caused artifacts and crashed in-game while I was testing it, so that's just bad:|. Heh, gotta find a different way.
Edit3:
Increasing FBO_OLD_AGE helps as well for the last entry, but I had to change it to around 20 from initial 5 and doing so breaks the whole list again if I cycle through whole menu going up or down since then it apparently needs to decimate quicker than when entering or leaving/re-entering menu, unless it then needs to redownload again and not doing it?:] Don't have any more ideas for now.
@unknownbrackets commented on GitHub (Aug 25, 2018):
Do either #11322 or #11323 help? It seems like they may from some data I saw, but not sure if it still requires an increased old age.
If it does, a few ideas:
-[Unknown]
@sum2012 commented on GitHub (Sep 2, 2018):
v1.6.3-404-ga004196d4 still show no font
https://gist.github.com/sum2012/1af1d0d4d1137a5e589eaba945737e71
@benderscruffy01 commented on GitHub (Mar 29, 2019):
v1.8.0-42-g62928e13d
still the same problem
DUMP.ZIP
@unknownbrackets commented on GitHub (Jul 7, 2019):
I wonder is this has the same issue as #10967 seems to, as noted above (in the JPCSP bug discussion.)
-[Unknown]
@ghost commented on GitHub (Jun 4, 2020):
Using ppsspp latest git build.
Both HW and SW rendering suffer the issue.
@nassau-tk commented on GitHub (Dec 9, 2020):
v1.10.3-1308 "Buffere Rendering & Simulate Blocktransfer ON"
OPTION's "O" appeared.
v1.10.3-1308 "NonBuffere Rendering & Simulate Blocktransfer ON"
"O" is missing...
ULJS00201_0001.zip
@sum2012 commented on GitHub (Dec 20, 2020):
The font "O" is fix by
github.com/hrydgard/ppsspp@f1a3ba7f56hehe ,this is scefont issue !?
But I use real psp of jpn.pgf ,"O" disappear
@nassau-tk commented on GitHub (Dec 20, 2020):
@sum2012
Hahaha~!!😝
Yes,That's right.
PSP Original PGF font is missing any character kind of this loop menu.
But,Kind of other menu (fixed position) is maybe no problem both.
And,I don't have clearly conviction that this game uses PGF font.
If "l" or "g" appear on the menu then I can check about "Is it PGF or not?".
[ Loop menu ]
Notice : These appeared first character is not correctly.
[ Fix position menu ]
@sum2012 commented on GitHub (Feb 14, 2021):
Small finding.If I disable black list "sceFont_Library" and "SceFont_Library",
32:28:756 user_main I[LOADER]: HLE\sceKernelModule.cpp:1332 Module sceFont_Library: 09ef7de0 09eef594 09eef5c0
32:28:756 user_main I[LOADER]: HLE\sceKernelModule.cpp:784 Function (sceReg,0cae832b) unresolved in 'sceFont_Library', storing for later resolving
32:28:756 user_main I[LOADER]: HLE\sceKernelModule.cpp:784 Function (sceReg,1d8a762e) unresolved in 'sceFont_Library', storing for later resolving
32:28:757 user_main I[LOADER]: HLE\sceKernelModule.cpp:784 Function (sceReg,28a8e98a) unresolved in 'sceFont_Library', storing for later resolving
32:28:757 user_main I[LOADER]: HLE\sceKernelModule.cpp:784 Function (sceReg,92e41280) unresolved in 'sceFont_Library', storing for later resolving
32:28:757 user_main I[LOADER]: HLE\sceKernelModule.cpp:784 Function (sceReg,d4475aa8) unresolved in 'sceFont_Library', storing for later resolving
32:28:757 user_main I[LOADER]: HLE\sceKernelModule.cpp:784 Function (sceReg,fa8a5739) unresolved in 'sceFont_Library', storing for later resolving
32:28:769 user_main I[LOADER]: HLE\sceKernelModule.cpp:1441 Exporting ent 0 named sceFont_Library, 0 funcs, 2 vars, resident 09eef644
32:28:769 user_main I[LOADER]: HLE\sceKernelModule.cpp:1441 Exporting ent 1 named sceLibFont, 28 funcs, 0 vars, resident 09eef660
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/02d7f94b, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/099ef33c, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/0da7535e, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/27f6e642, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/2f67356a, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/3aea8cb6, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/3c4b7e82, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/472694cd, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/48293280, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/48b06520, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/5333322d, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/568be516, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/574b6fbc, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/57fcb733, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/5c3e4a9e, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/5dcf6858, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/67f17ed7, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/681e61a7, already implemented in HLE.
32:28:769 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/74b21701, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/980f4895, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/a834319d, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/aa3de7b5, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/bb8e7fe6, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/bc75d85b, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/ca1e6945, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/dcc80c2f, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/ee232411, already implemented in HLE.
32:28:770 user_main W[LOADER]: HLE\sceKernelModule.cpp:795 Ignoring func export sceLibFont/f8f0752e, already implemented in HLE.
32:28:770 user_main I[SCEMODULE]: HLE\sceKernelModule.cpp:2040 296=sceKernelLoadModule(name=disc0:/PSP_GAME/USRDIR/FONT/LIBFONT.PRX,flag=00000000,(...))
Which mean that it use custom scefont library
@unknownbrackets commented on GitHub (Aug 21, 2022):
The dump works okay on hardware too, which only confirms the previous findings. It also makes me think that the stall updating issue may be resolved now.
It sounds like there's just one issue remaining. My assumption is the game does this:
In the software renderer, temporary surfaces are stored in RAM (just like on the PSP.) This means they're permanent (as long as the game is running), they're always updated by CPU activity, and they are never accidentally overwritten by unrelated rendering.
The hardware renderer, however, creates actual temporary surfaces on your GPU. They don't exist in RAM, and moreover... it's hard to tell what's safe to update in RAM. Some types of updates from the CPU don't update them, so if one isn't used for a while we start thinking it must be old and wrong (if we didn't do this, characters would be walking around with "NEW GAME" instead of faces, because we didn't notice it loading the face with the CPU.)
So - presumably - if we made temporary surfaces immortal (hello NEW GAME faces), it would "fix" this bug. That would support my assumptions above, but wouldn't truly be a way to fix this issue.
Another thing we tried to do was determine a "safe size" to update in RAM. For complex reasons, we don't even know what part of RAM was actually updated by drawing in the hardware renderers. If we blindly update RAM after rendering, it makes games crash because we delete important data. So we watch for signals for what RAM should be updated. It seems like this game isn't doing any of the things we normally watch for to figure that out.
The most helpful frame dump now would be a frame dump for when it actually draws the temporary surfaces. It's definitely before you see the "NEW GAME" on screen, but you would see if while stepping through the GE debugger. However, this would be hard to capture because by the time you see it in the GE debugger, you're already one frame too late to create a frame dump of it. It's only drawing those temporary surfaces once (if my assumptions are correct.)
Another, simpler thing that could be happening is that we could be misdetecting the texturing as coming from an offset into the wrong surface. Or it could be rendering these all together to a single temporary surface, but then texturing from offsets, and we could be missing that.
Just wanted to collect all the information about the issue here.
-[Unknown]
@IrfanH495 commented on GitHub (Feb 25, 2023):
I tried to bring up the missing text using textures but the result is that in any menu
1 New game
2 continue
did i make a mistake while making it texture
@nassau-tk commented on GitHub (Feb 25, 2023):
Probably, It will relate PGF issue too.
Because, Shape of "I" was make by me.
@IrfanH495 commented on GitHub (Feb 26, 2023):
2xpsp
vulkan
frame skipping 1
https://user-images.githubusercontent.com/78854859/221393888-87fc619d-6408-401d-a69a-1b68cd96c00d.mp4
the text appears but I can't save it as a texture.png
@unknownbrackets commented on GitHub (Feb 26, 2023):
Unfortunately, this game is doing something very "anti-frameskip", in that it's drawing some graphics only once and reusing them. Frameskip skips entire frames for speed, and if it skips one of these "key" frames where one-time drawing occurs, there will be problems.
Unfortunately, the game doesn't tell us whether the drawing is one time or not so we can't tell until after we've already skipped it...
As far as saving as a PNG, does it help to change the texture hash method in textures.ini?
-[Unknown]
@IrfanH495 commented on GitHub (Feb 26, 2023):
I've tried it but still the texture doesn't appear
I've also tried installing textures taken from software rendering, but they don't appear.
texture from software rendering
texture vulkan
maybe I'm just too stupid,
I don't know how to make textures other than following the method on YouTube.
@unknownbrackets commented on GitHub (Feb 26, 2023):
Well, it's probably not a texture like that.
The game is drawing CONTINUE to a framebuffer and using that as a texture. You can't replace dynamically rendered framebuffers in texture packs. Instead, you'd need to replace whatever texture it initially uses when drawing CONTINUE. I assume that's something more like a grid of letters.
-[Unknown]
@sum2012 commented on GitHub (Nov 3, 2025):
I ask AI, it answered "The issue was in the PSP font rendering system (Core/Font/PGF.cpp) where:
EVA fonts use very low alpha values (1-15 range) that become invisible during rendering
The original pixel enhancement logic didn't provide sufficient visibility boost for these fonts
Font pixels with very low alpha values were being written but remained practically invisible" but it doesn't give perfect solve ( I tested 16 times)
code change:
github.com/hrydgard/ppsspp@fe104ded3f@sum2012 commented on GitHub (Nov 3, 2025):
Second try best, will test further before pull request
github.com/hrydgard/ppsspp@7b7567da67