mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-24 21:56:10 +03:00
[GH-ISSUE #4955] Graphic glitch on white knight chronicles #2073
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#2073
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 @daniel229 on GitHub (Dec 31, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/4955
Head drop to leg.

@unknownbrackets commented on GitHub (Dec 31, 2013):
Is this new or has it always happened?
-[Unknown]
@daniel229 commented on GitHub (Dec 31, 2013):
The savedate works since 0.95-404,It happened on that build,but I think that savedata slots do not work correct.the four below slots should display nothing.

psp
@daniel229 commented on GitHub (Dec 31, 2013):
The created slot is fine

@unknownbrackets commented on GitHub (Jan 18, 2014):
Is this affected by software skinning or prescale texture coordinates? Also, how does it look in softgpu?
I think that the savedata change that made this game work is not actually correct (I thought that then and I still think it now.) It's probably what is causing Lv 0 etc. That said, it's not clear if it's actually breaking anything, and I'm not sure what the correct change would be...
-[Unknown]
@daniel229 commented on GitHub (Jan 18, 2014):
Software skinning,Texture coord speedhack,Software rendering don't change anything
@dbz400 commented on GitHub (Jan 18, 2014):
Yep , the character for new save and load looks fine . However , when loading up data , "Lv 0 0:00: 00" should be showing as NO DATA .
Saving data

Loading data

@dbz400 commented on GitHub (Jan 18, 2014):
It try to load 2nd-5th slot somehow and got lots of invalid address if you try to select them and also renders those character wrong with leg/arm
55:26:498 user_main I[UTIL]: Dialog\SavedataParam.cpp:547 Loading file with size 131072 in ms0:/PSP/SAVEDATA/UCES01511/SCENAR0.BIN
55:26:630 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:61 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
55:26:665 user_main I[UTIL]: Dialog\SavedataParam.cpp:547 Loading file with size 131072 in ms0:/PSP/SAVEDATA/UCES01511/SCENAR1.BIN
55:26:665 user_main E[FileSys]: FileSystems\DirectoryFileSystem.cpp:462 DirectoryFileSystem::OpenFile: FAILED, 2 - access = 1
55:26:665 user_main E[UTIL]: Dialog\SavedataParam.cpp:551 Error reading file ms0:/PSP/SAVEDATA/UCES01511/SCENAR1.BIN
55:26:665 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:970 Has not been saved yet, just skip.
55:26:797 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:61 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
55:26:831 user_main I[UTIL]: Dialog\SavedataParam.cpp:547 Loading file with size 131072 in ms0:/PSP/SAVEDATA/UCES01511/SCENAR2.BIN
55:26:831 user_main E[FileSys]: FileSystems\DirectoryFileSystem.cpp:462 DirectoryFileSystem::OpenFile: FAILED, 2 - access = 1
55:26:831 user_main E[UTIL]: Dialog\SavedataParam.cpp:551 Error reading file ms0:/PSP/SAVEDATA/UCES01511/SCENAR2.BIN
55:26:831 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:970 Has not been saved yet, just skip.
55:26:965 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:61 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
55:26:998 user_main I[UTIL]: Dialog\SavedataParam.cpp:547 Loading file with size 131072 in ms0:/PSP/SAVEDATA/UCES01511/SCENAR3.BIN
55:26:998 user_main E[FileSys]: FileSystems\DirectoryFileSystem.cpp:462 DirectoryFileSystem::OpenFile: FAILED, 2 - access = 1
55:26:998 user_main E[UTIL]: Dialog\SavedataParam.cpp:551 Error reading file ms0:/PSP/SAVEDATA/UCES01511/SCENAR3.BIN
55:26:998 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:970 Has not been saved yet, just skip.
55:27:132 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:61 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
55:27:165 user_main I[UTIL]: Dialog\SavedataParam.cpp:547 Loading file with size 131072 in ms0:/PSP/SAVEDATA/UCES01511/SCENAR4.BIN
55:27:166 user_main E[FileSys]: FileSystems\DirectoryFileSystem.cpp:462 DirectoryFileSystem::OpenFile: FAILED, 2 - access = 1
55:27:166 user_main E[UTIL]: Dialog\SavedataParam.cpp:551 Error reading file ms0:/PSP/SAVEDATA/UCES01511/SCENAR4.BIN
55:27:166 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:970 Has not been saved yet, just skip.
@dbz400 commented on GitHub (Jan 18, 2014):
Those SCENAR1.BIN/2.BIN/3.BIN/4.BIN shouldn't be tried to load as they not exists
@unknownbrackets commented on GitHub (Jan 18, 2014):
Oh, I didn't understand, so it's only rendering wrong when selecting a save slot that is broken? So this isn't a graphic issue at all, really. It's purely a save issue.
Right. The change I talked about above was to lie to the game and say that they do exist. Surprisingly, it seems to have not broken many other games, and it actually fixed this one although I think it's still not right for the reason you just stated.
-[Unknown]
@dbz400 commented on GitHub (Jan 18, 2014):
Yes , those broken rendering only appears when we are selecting broken/non-existent slots . If we selected a correct/existent slot , rendering characters all look good.
@dbz400 commented on GitHub (Jan 18, 2014):
I think this code makes it work
if (param.secureCanSkip(param.GetPspParam(),param.GetPspParam()->mode == SCE_UTILITY_SAVEDATA_TYPE_READDATASECURE)) {
INFO_LOG(SCEUTILITY,"Has not been saved yet, just skip.");
param.GetPspParam()->common.result = 0;
}
@dbz400 commented on GitHub (Jan 18, 2014):
Wondering we can add simply check the existent of those securefilename that got from PARAM.SFO
@dbz400 commented on GitHub (Feb 16, 2014):
Checked with lates build here , issue remains
56:33:868 user_main I[UTIL]: Dialog\SavedataParam.cpp:536 Loading file with size 24576 in ms0:/PSP/SAVEDATA/UCES01511/SYSTEM.BIN
56:33:968 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:67 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
56:34:168 user_main I[UTIL]: Dialog\SavedataParam.cpp:536 Loading file with size 131072 in ms0:/PSP/SAVEDATA/UCES01511/SCENAR0.BIN
56:34:269 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:67 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
56:34:470 user_main I[UTIL]: Dialog\SavedataParam.cpp:536 Loading file with size 131072 in ms0:/PSP/SAVEDATA/UCES01511/SCENAR1.BIN
56:34:570 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:67 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
56:34:769 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:980 Has not been saved yet, just skip.
56:34:869 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:67 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
56:35:068 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:980 Has not been saved yet, just skip.
56:35:170 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:67 sceUtilitySavedataInitStart(08ba5a54) : Mode = 15
56:35:370 user_main I[UTIL]: Dialog\PSPSaveDialog.cpp:980 Has not been saved yet, just skip.
@unknownbrackets commented on GitHub (Feb 16, 2014):
I think that the "secureCanSkip" functionality isn't exactly right, but I'm not really sure what is right.
It still does not work correctly if you revert #4514, right?
-[Unknown]
@daniel229 commented on GitHub (Feb 16, 2014):
revert that,then it wont load savedata.

@daniel229 commented on GitHub (Oct 1, 2014):
how about do it like jpcsp,it works fine. https://code.google.com/p/jpcsp/source/browse/trunk/src/jpcsp/HLE/modules150/sceUtility.java#1470

@unknownbrackets commented on GitHub (Oct 1, 2014):
Are we sure that code doesn't just mean "file is not encrypted"? Is that what's happening here (that would be relatively easy to test, if so)? It seems weird to return "file not found" for a file that exists.
Oh wait, it's just that the SFO exists but the file doesn't, I see. Still wonder if it's only for READDATASECURE. If it isn't, it might be that "RW_NO_DATA" means "SAVEDATA doesn't exist" and this other one means "SAVEDATA does exist, but file does not." Maybe it even should apply to other modes...
But yeah, sounds like the error code is just wrong one way or another. Nice investigation.
-[Unknown]
@daniel229 commented on GitHub (Oct 1, 2014):
it check the file one by one, the slot 1(SCENAR0.BIN) and slot 2(SCENAR1.BIN) have a file exits,but the third slot file(SCENAR2.BIN) is not exist.

@daniel229 commented on GitHub (Oct 1, 2014):
Test on PSP,
remove the PARAM,reports 80110326,
remove SYSTEM.BIN,reports 80110329,
remove the directory,80110327.
@daniel229 commented on GitHub (Oct 1, 2014):
How about this,It returns error like on PSP.
https://github.com/daniel229/ppsspp/compare/savedata?expand=1
@daniel229 commented on GitHub (Oct 1, 2014):
Other modes,don't know how to test on psp.
@unknownbrackets commented on GitHub (Oct 3, 2014):
To me that looks definitely much more likely to be correct. We'll have to create a pspautotests test for the rest.
-[Unknown]
@daniel229 commented on GitHub (Oct 3, 2014):
Thanks,then I sent a pull request.https://github.com/hrydgard/ppsspp/pull/6969