Search
Member List
Calendar
Help
forums.PPSSPP.org
/
PPSSPP - Playstation Portable Simulator Suitable for Playing Portably
/
Development 
/
[Discussion] 60FPS patches for PSP games that run at 30FPS
/
[Discussion] 60FPS patches for PSP games that run at 30FPS
|
[Discussion] 60FPS patches for PSP games that run at 30FPS
|
|
03-20-2015, 02:08 PM
(This post was last modified: 03-25-2015 01:18 AM by LunaMoo.)
 Post: #366 |
|||
|
|||
|
RE: 60FPS patches for PSP games that run at 30FPS
@Goshorai well patches can be long because asm code just ends up visually long as it's very basic and when you don't have room to place your code inside game functions you also have to jump to a code cave(basically a part of memory which is always empty ~ I usually use 0x08800000-0x08804000) and return keeping opcode replaced with jump as well which makes it even longer. It's not a problem for the game, because what seems visually long is actually still very short and executed instantly, it might be a problem for ppsspp cheat engine which can cause random freeezes refreshing long asm codes but 0xE type code is there to avoid it by making sure it's patched only once.
Black screen, freezes, crashes, when you're experimenting with things instead of properly checking everything is pretty normal and experimenting is probably the only way until you learn a bit of mips assembly and learn what syscalls you're patching do and what parameters they might take(I don't think I mentioned that earlier other than linking to some pdf, but parameters are stored in "a" while return values in "v" registers), nopping stuff is not exactly safest way around;3. Disassembly itself is not exactly an isle of stability, but your problem is not related to that, you either broke the way game displays graphics or pushed the code into an endless loop. You'll just have to find a different way. Probably best way to understand what's happening is setting a breakpoint on the start of the function, or at least before the place we're interested and click "step into" while observing how instructions are executed and what happens with registers they're messing with. For simpler opcodes it might be easier way to learn what they do by observing that way than reading some documents which are usually written in very complex/scientific language. With time you start seeing things more naturally. I didn't really thought about patching all my collection, don't really plan anything, if I see any more game which I can patch I will. And I don't want anyone to think game x is too hard because I or someone else was not able to do it, humans are just humans, what one misses can be obvious for another, just have to try. Changing speed which is required in most games, might be sometimes a challange, maybe even like trying to find a needle in a haystack and I guess noone is interested in sitting there and manually tracing the code trying to find out everything he needs to patch it. But that's not the only way, we can always think about other ways, I didn't really gave up completely on any game, I just for the time being don't have any more ideas how to burn that hay or magnet out that needle in games like MH.:| @cybercjt Sorry only E2, but if you tried and the patch doesn't work in E1, it's same game definitely differs less from E2 than VCIII from VCII  , so at worst it's probably just a slight difference in address, you could check those three addresses in disassembly: 0x08BA99B0, 0x08847CC0 and 0x08847FC0 and look up and down a few pages until you see same things as:(decreased color pallete to keep size low as it's not important, you'll see different ones anyway) Then just copy addresses of those lines you find in your and replace them in the cheat, values should be same except for disable code which if you want you'll have to right click on jal zz_sceDisplayWaitVblankStartCB and "copy instruction (hex)" then paste it instead of "0E32665A" in the disable code. Also after doing all of that you can remove "_L 0xE.." line completely, it shouldn't be needed for short cheats anyway, I just got used to it and add it automatically to all my cheats from some time;p. Edit: Code: _S NPJH-50721Code: _S UCES-01327Next day edit: Made it as a proof of concept, just to show that it is possible to patch any game to 60 fps and how much stuff has to be patched to make it for those mh games;c. Cannot be easily ported to other MH games except for the fps unlock itself because life happens it's also likely imperfect althrough playable and very smooth, for now I'm taking a break. Those games are really bothersome to patch, not sure if I repeat that, so I picked 2nd G as it has most content and was easier than 3rd HD from which I started and gaved up a few times earlier;p. Now nobody can say "it's impossible" so good luck patching other games:3. Code: _S ULJM-05500Edit: changelog - fixed lots of small activities which had double speed, stamina consumption/regen and camera control Update: - fixed climbing speed, GS charge speed, also decided to force 2x speed in old cave during mining animation since for now it's the only way I could sync it, body disappearing timer and 20s to quest finish timer, I don't think I'll bother with correcting 2 minutes after quest ends since 1 minute is more than enough time. Things left? Probably, because this game loves to piss me off with how it's doing everything, to the point I want to give up on 3rd completely, every time I patch something I notice something else while testing . Most of the time it's not even hard, just bothersome and boring.
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. |
|||
|
|
« Next Oldest | Next Newest »
|