Mouse support?

[bigphil2695]

Is there a mouse support mod for the PPSSPP emulator?

[LunaMoo]

Mouse is supported from quite a while, but only for windows(it has to be enabled on the bottom of the controls config screen then mapped in control mapping screen), other operating systems will be supported when/if some dev that uses that operating system will implement it aka might not happen anytime soon since AFAIK nobody was working on mouse support for any other OS at least not openly.

Note that even on windows mouse works best when mapped to analog and even better if game is patched to use true analog input(most psp doesn't use analog and those which do often limit it to 8 direction and 2-3 sensitivity levels which sucks, but fits the hardware since analog thumbstick on psp also sucked and was nowhere close to real size gamepad or mouse accuracy).
When mapped to keys mouse will still input as analog and then translated to key affected by analog to key threshold which isn't configurable in the official version and as result it'll include slight delay.

[Rekrul]

(06-03-2019 10:53 PM)bigphil2695 Wrote:  Is there a mouse support mod for the PPSSPP emulator?

If you want to use the mouse to input the face buttons, such as for an FPS game that uses the face buttons for controlling the camera control, you'll need to use the external program GlovePIE. PPSSPP's own routines for doing this are crap.

See this post which gives information about using it with the game Dark Forces and includes a download link;

https://steamcommunity.com/sharedfiles/f...=286364447

And see my post here for a GlovePIE script that will map the default PPSSPP keyboard controls to the mouse movements;

https://forums.ppsspp.org/showthread.php...ight=mouse

NOTE: Depending on the game settings, this may give you "normal" or "inverted" control. If the game doesn't let you change it, just swap the "S" and "Z" in the script to reverse the forward/back movement.

Using this method isn't as good as having true mouselook, but it's better than using the face buttons for controlling the camera.

[FOPSP]

(06-04-2019 08:05 PM)LunaMoo Wrote:  Note that even on windows mouse works best when mapped to analog and even better if game is patched to use true analog input

Where can I find those patches? I haven't seen any.

[LunaMoo]

There aren't that many. Kabuto-kun potentially made some similar patches, but dunno really. I always posted mine in each game's thread, but nowadays they can also be found in my PPSSPP_workarounds repo on github.
You can find it there for:
- CODED ARMS (US),
- Ghost in the Shell: Stand Alone Complex (US),
- Metal Gear Solid: Peace Walker (US/EU),
- Initial D: Street Stage (JP).

The last one was more as an example to avoid limiting people into thinking that such patches can only be done for camera/aim control as I made it there for acceleration. Overall I really made those patches because some people were making analog patches for PSP games on PS Vita, however they were I belive only remapping controls via some plugin, were limited to games that already could use analog etc. and overall remapping sucks compared to patching-in the real thing. I hoped to show people it is possible and make fans of each series do the rest, but it never gained any popularity despite being a clean enhancement and not a buggy gameplay breaking thing which ever popular 60 fps patches commonly are.


Pressing buttons via analog also sucks similar to the vita thing, however in case of PPSSPP it involves an additional threeshold that means key is only pressed via analog if analog angle is over 75%, imo that threeshold is too big and my personal builds have an option to control it, however due to some potential bug not having any threeshold might keep some tiny analog movements even when we don't move it, so it's still not recommended to just remove all threeshold.

Using analog as analog doesn't have anything like that and mouse movement(delta) is directly translated to analog angles hence mouse works nicely there and because of that all of such patches would potentially make mouse control work better.
However while such patches are already great for analog sticks, if we consider mouse that's not all and with a bit more work which I did only for MGSW patches further enhancement is possible where I additionally added a more robust speed control. This allows the player to set the speed of the camera to a much higher values than normally possible and with just a bit of tweaking it feels like a real "mouse control" where you can turn 360 degrees by just moving your hand a bit further while still being able to accurately aim into smaller things. Pretty much it turns Peace Walker into a poor man's Phantom Pain.

[Rekrul]

(07-06-2019 01:19 PM)LunaMoo Wrote:  I hoped to show people it is possible and make fans of each series do the rest, but it never gained any popularity despite being a clean enhancement and not a buggy gameplay breaking thing which ever popular 60 fps patches commonly are.

Perhaps the fans of the games don't have the knowledge or skill to write such patches and the people who do have the knowledge and skill aren't interested enough in the games to do it. I don't know exactly what's involved, but I imagine that patching a game from reading an analog stick to using a mouse probably involves more than changing some parameters.

I'm not trying to be hostile, so please don't take this as me trying to bait you. Many people, myself included, would love to be able to make such patches, but we just don't have the talent to do it. You can say that we should just learn, but learning programming doesn't come that easily to everyone. I learned BASIC and assembly on the C64, which is a far simpler system, but I was never very good at either. My BASIC programs were slow and inefficient, and I could only write short routines in assembly before being overwhelmed. I've tried to disassemble small Flash games to unlock them so that they will play from a local file and have failed miserably at that. I struggle to write Windows batch scripts that use variables because there's always something I'm unaware of that trips me up.

I know some people just assume that they can't do something so they're afraid to try. I've tried and the results weren't all that encouraging. It's not a lack of desire on my part, I want to be able to write my own programs and patches. I'm just not very good at it.

[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.

[Rekrul]

(07-06-2019 11:20 PM)LunaMoo Wrote:  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.

Thank you for the detailed explanation. I understand the concept, but got lost trying to understand the code. It's similar to how I was told to make trainers (cheats) for C64 games; Find where the game prints the number of lives/energy/etc to the screen, determine what it's based on, then backtrack to find out what part of the program changes that value. I never had much luck dong that.

[LunaMoo]

After #12173 and #12176 get's merged, mouse will not keep tiny values when using small axis to button threshold and as such include only minimal threshold to react on even tiny mouse move / without delay, it'll also avoid using mapped PSP keys in UI as this could be problematic especially when mapping it to cross or circle.

If someone wants to test mouse movement in a visible way after those patches get merged, I would recommend mapping mouse to left analog and d-pad and using touch screen controls, that's also a good way to find out what sensitivity and smoothing settings you might like for the mouse as it shows exactly how mouse mapped to analog/buttons behaves and gives better idea why I even added those settings in the first place.

Edit: Both of my PR were merged improving mouse control, so I'd recommend using version v1.8.0-424-geeb349121 or above to play with a mouse.

[Merlou]

LunaMoo i want to Learn. I'm beginner, french, dont have computer only my phone Android and tablet, and i've Never use github more than sending messages. I want to play FPS with mouse as it feels on computer. I tried to Map with PPSSPP options but it's not good. Could you tell me what i should start with to Learn ? Thank you