Mouse support?

[LunaMoo]

Making a 60 fps patch to a game which doesn't have some kind of switch left over by game devs also means more than changing a parameter, in fact it involves much more work since code optimization through compilers makes it pretty awful to work with I made a lot of 60 fps patches that I never mentioned anywhere since it would take too long to make them usable and could be impossible to make them perfect and still regret posting a few too early like Monster Hunter ones which I gave up on completely.



In comparison making a true analog patch means:
Short version:
- finding speed and where it is applied and providing info based on the analog stick angles instead.


Long version:
a) checking(not even "finding" since it's just out there via known syscall) where the game checks input,
b) hooking to it a mostly reusable/universal code to write down some info we can access later, most of the analog patches code is copy&paste,
c) finding speed of what we want to affect, for example moving camera right with locked keys and frame by frame searching for value that increases now we know where the game stores the acceleration for that camera direction,
d) when we check what writes to that value, we can remove the math that increases the value while key is pressed and instead replace it with a simple logic that checks if analog is being moved in the right direction and if yes, apply the speed based on actual angle, we prepare both info if specific analog direction is pressed as 1/0(yes/no) earlier in step b) same as for the actual speed to move based on the analog angle,
e) repeat the last two for all directions.

This can be applied to any situation where analog control would have any sense, prefferably if animations already supports it or if animations doesn't matter.

Game modding doesn't require much programming knowledge, mips is scary, but also is very easy when all you need is a few english-sounding opcodes for all your math and reading/writing to memory.

Just look at this which is the function that I mentioned in b) as mostly(with slight changes) reusable in all games:
   

And now try line by line to understand what it does using internet to google for each opcode you don't know, for example here you have most of the common ones: http://www.mrc.uidaho.edu/mrc/people/jff...IPSir.html
1. First line is just moving value of "sp" register into "t7" register and this is probably a leftover from some other game I patched earlier as I could have used "sp" register directly here, either way it stores location where input is written by sceCtrlReadBufferPositive syscall.
2. Sets a value 0x08800000 to a register "t1"
3. Copies that value to register "t8"
4. Sets a value of 0x20 to register "t2" - this is a deadzone left as editable by the user and some math after it will be directly related
5. Sets a value of 0x80 to a "t3" register (angles of the analog sticks goes from 0x00 to 0xFF, 0x80 is the center position)
6. Add's values of t2 and t3 and stores the result in t4
7. Increases t4 by 0x1
8. Reduces t3 by t2 and keeps the result in t3
9. Sets t6 to a 0x3F800000 value (1.0) which again is left configurable to the user as the camera speed
10. Moves value of t6 register into f30 register of the coprocesor1
11. Loads unsigned byte from an address of (value of t7 register + 0xA) into t0
12. sets t5 to 1 if t0 is less than t3
13. Saves byte value of t5 to a location of t1 value + 0xFFC ~ initially into 0x08800FFC, but if you read later on, t1 will be increased
14. sets t5 to 1 if t4 is less than t0
15. Saves byte value of t5 to a location of t1 value + 0xFFD ~ initially into 0x08800FFC, but if you read later on, t1 will be increased
~ now you should have a rought understanding that we tested for 2 analog directions and saved a short info whenever they are used (1) or not (0) and as you can imagine we will later as mentioned increase t1 to go through another 2 analog directions.

If someone wants to learn just go through the rest yourself and best, just use one of the existing patches on some game and look at it in disassembly while the game is running to observe exactly what it does which makes things much clearer to understand, note that the code could be shorter if I didn't cared about making it user configurable or if I didn't cared about it providing easy to interpret info not just to make the code more portable, but also to avoid having to hook separate functions when game checks for standard buttons being pressed where I simply check whenever analog direction is used, that part is not on the screenshot, but while it's even easier to understand it will differ per game.
That function is also somewhat different per game as in this case game used floating point for speed, but there are games which can use integer values etc also registers we can use will differ depending on where we hook that function, typically it would be shortly after syscall like sceCtrlReadBufferPositive and the nice part about syscalls is that they reset temporary registers values, hence we are mostly free to use temp registers(t0-t7). Also location where do we look for analog values can be fund by arguments passed to sceCtrlReadBufferPositive syscall. Arguments are basically values set to a# registers before jumping to syscall, in this case a0 is where the syscall will write values of used input and we just offset it by 0xA to get right analog stick ~ yes that syscall returns values of right analog stick even through hardware side it never existed on PSP.

Important to note, this is not the only, nor the easiest way of patching a game to work that way, it's just my way. Initially I had the idea of finding camera movement speed, then patching it via external cheat engine based on mouse delta(using cheat engine lua scripting), but back then there was a bug I didn't understood which made this impossible due to not being able to freeze values in PPSSPP via Cheat Engine(which turned out to be a windows bug and needed a workaround on Cheat Engine side), so when I heard about others patching right analog support to PSP games on Vita I just had the idea to simplify the concept and get rid of external tools and scripting writing the whole thing completely in assembly.

I wrote that backstory to say that lua thing is actually easier and Henrik mentioned that it would be nice to have lua scripting at some point, that doesn't mean he's interested in implementing it, but it's an open door to anyone willing and with lua scripting such patches would really be just finding some values and writing short lua code to do things with it. Lua is basically english, anyone who communicates on the international net can code in it and that lenghty mips function I provided screenshot of, could be reduced to just few lines.