04-27-2014, 12:28 AM
@denslife16 I can already tell that it's not that latest version doesn't crash during missions, as I said in one of my posts earlier which described the game problems(the very same that @Raimoo quoted like a page ago
), crashes during missions happens only once only during first savestate(or some time after) and after loading that savestate after crash or even after emulation restart, you can spam savestates and it'll never ever crash again(until next mission that is;]), just like @vsub_ says he does with the demo.
You can do it still on the modified build, it does not matter as long as you restart it or launch it again after crash at least that's how it is on windows, also the game will absolutely never crash during a mission IF you never use savestate, as simple as it is, I played loads of long missions without any fear of crash.
Latest version doesn't have any improvement over older ones, I tried last time like yesterday when I was messing with the game trying to find a different way of fixing it, so I'm pretty sure of that.
Basically what we know about the problem is that some modules have to be loaded one way, others in different way, we have absolutely no clue as of now how games decide which should load how:C, loading all of them the opposite way of normal builds is our current workaround, but it's just breaking the game slightly less, to fix it completely we would have to make a system that detects properly how the game wants those modules loaded, and as of now I guess nobody has an idea how to make it. We could easily build a version that changes the method of loading modules based on our own list, but if the game would need to load same modules in different way depending what it does it would still fail.
With the info I gathered - unmodified build which loads all modules on the start of memory results in addresses(GE2 1.30) shifted by +0x14A00 in compare to real psp, our modded build that loads them on top results in addresses shifted by -0x1600 in compare to real psp, untill we find a way that doesn't shift memory at all, the game will have it's issues, through they can change with game version and maybe even get completely hidden in some of the newer update. Why I even consider such possibility? Because actually GE/GEB also suffers from the very same problem, it's memory is also shifted which you can seen by looking at CW cheat implementation that has built in offset for this game as seen here:
luckily this problem doesn't break anything(?) in those games.
), crashes during missions happens only once only during first savestate(or some time after) and after loading that savestate after crash or even after emulation restart, you can spam savestates and it'll never ever crash again(until next mission that is;]), just like @vsub_ says he does with the demo.You can do it still on the modified build, it does not matter as long as you restart it or launch it again after crash at least that's how it is on windows, also the game will absolutely never crash during a mission IF you never use savestate, as simple as it is, I played loads of long missions without any fear of crash.
Latest version doesn't have any improvement over older ones, I tried last time like yesterday when I was messing with the game trying to find a different way of fixing it, so I'm pretty sure of that.
Basically what we know about the problem is that some modules have to be loaded one way, others in different way, we have absolutely no clue as of now how games decide which should load how:C, loading all of them the opposite way of normal builds is our current workaround, but it's just breaking the game slightly less, to fix it completely we would have to make a system that detects properly how the game wants those modules loaded, and as of now I guess nobody has an idea how to make it. We could easily build a version that changes the method of loading modules based on our own list, but if the game would need to load same modules in different way depending what it does it would still fail.
With the info I gathered - unmodified build which loads all modules on the start of memory results in addresses(GE2 1.30) shifted by +0x14A00 in compare to real psp, our modded build that loads them on top results in addresses shifted by -0x1600 in compare to real psp, untill we find a way that doesn't shift memory at all, the game will have it's issues, through they can change with game version and maybe even get completely hidden in some of the newer update. Why I even consider such possibility? Because actually GE/GEB also suffers from the very same problem, it's memory is also shifted which you can seen by looking at CW cheat implementation that has built in offset for this game as seen here:
Code:
if (gameTitle == "ULUS10563" || gameTitle == "ULJS-00351" || gameTitle == "NPJH50352" ) //Offset to make God Eater Burst codes work
address -= 0x7EF00;
http://forums.ppsspp.org/showthread.php?tid=6594 - Custom PPSSPP Shaders!
http://forums.ppsspp.org/showthread.php?tid=3590&pid=117172#pid117172 - simple CE scripts to help creating CWCheats,
https://github.com/LunaMoo/PPSSPP_workarounds - CWCheat workarounds.
http://forums.ppsspp.org/showthread.php?tid=3590&pid=117172#pid117172 - simple CE scripts to help creating CWCheats,
https://github.com/LunaMoo/PPSSPP_workarounds - CWCheat workarounds.

