[Reive]

So I've had this in my head for years that I wanted to play the original Otogi without the backwards X-Axis controls, while the sequel did fix this by giving you options the original is fully inverted and unchanegable, I love the game a lot and wanted to correct this.
I know next to nothing about hacking but I do have a modded xbox, most of the information on creating trainers/patches via debgugging on an actual console are lost and the tools outdated so I decided to go a round about way and try to find the camera value addresses for the game via emulator.
CXBX can only manage to get in game, which is good enough as long as I can move the camera I can find the values via cheatengine, which I did, it happpens to be 013D3BD8

However this is where I'm stuck, I know the address but that's it, loading it into the memory viewer shows the instructions for how it's handled but I have literally no idea what anything is and what can be changed to create an inversion.

I followed a tutorial video that showed how to do this for a pc game, the problem I'm currently at is that the opcodes availiable in the pc game was as easy as changing an add function to subtract, wereas the memory area of my address doesn't seem to have anything that simple.

Here's an image of the memory viewer in the space I'm looking at, the highlighted green number being the camera address and value itself, and the highlited blue being what writes to that address



I'd really appreciate it if someone could help me make this a reality!

[FAST6191]

You can go that way. I would probably approach it as a control hack.

Before going too much further you do have the hardware approach, which has the added bonus of only working for that controller, working in other games and working on unmodded xboxes (I don't know who would have such a thing but I note it anyway).
General idea is desolder the vertical pins of the stick (though x axis here might mean those, might as well do both though as plenty of games still suffered from cretin camera for vertical stuff), swap them around and there you go. Can even chuck a few more wires and a suitable switch to have it go back and forth depending upon your whims. Even mediocre electrical skills can probably get this done an evening project, without skills in software this is on the more advanced side of things, especially for the xbox as debugging that is a pain and emulation is not up to too much (though getting better rapidly).

Anyway software based stuff, sadly I don't think the original xbox has enough of a kernel that you can do it there (you can on the 360, 3ds and obviously PC, anything with a hacked kernel running in the background is probably handling controls for the game so you can attack that for your control modding purposes on those) Control hacks then. Several approaches depending upon what is going on.

1) Somewhere in memory is every frame or so the state of the buttons. Good coders will not use this directly but instead copy once a frame and have everything operate from that. This is as it dodges some issues with bouncing -- switches are mechanical devices rather than clean ideal binary devices and might display everything from invalid voltages to flickering between values as things settle, which is annoying when one part of an action sees the button pressed and acts accordingly but something else checks and finds it different despite only being nanoseconds later and then we get oddities, as more than one button press happens in the average game the chances of controls failing you (a bad thing in game design) you debounce things.

Anyway sticks are analogue so you get analogue values rather than on or off. Same idea though as you are either going to do the reverse of the value the system presented (if it is say between -127 and 128 then if it is minus then make it positive, if it is positive then make it negative, or if it is a simple range then... yeah), or change what the game reads (in horrible psuedocode READ button state, if X axis is between ? and 0 do according movement, if between 0 and # then do according movement though the opposite of the last one, easy enough then to make it look at another stick, or take the other path that normally gets selected by the other direction).
If there is any kind of button mapping in the game, even "premade selection we think you will like" then there might well be further options. If there is a sensitivity option it might also get in the way or be a factor in the distance moved.

I don't know what we have for xbox hardware listings -- homebrew sdks might know, possibly commercial ones (by this time they had gone away from hardware documentation and instead gave devs libraries), emulator source code and wikis. There is a possibility you can find such things with cheats but eh. If you wanted to continue with the camera value and work backwards from there for anything altering it (will need a debugger you can set breakpoints in, find the camera and then set a break on write, move the stick and now we are off. https://www.romhacking.net/documents/361/ is for the GBA but the same principles apply for basically everything when it comes to tracing as it is known. Hopefully the camera is in part of memory your cheat program can see and manipulate as well -- the xbox was basically a PC so you do have directX after a fashion which is fairly fully featured 3d rather than the more primitive stuff seen in other devices of earlier years (or later handhelds -- the DS was still pretty primitive as these things go).

If you need to change any tutorials or on screen prompts as part of this then that lands us in text and graphics hacking world, possibly audio as well as it was a space year where you could afford to have hours of audio without breaking storage limits.

[Reive]

I appreciate the ideas, I would have done a hardware mod to a controller but I both don't want to sacrifice a controller to be permanently inverted and creating a switch to turn it on and off is beyond what I know how to do with electronics.
Ideally I'd want to make a patch not try to do a system level hack, I really wish we had something as easy as the PS2 Remapper tool but for Xbox, but the ps2 seems to keep all it's input information upfront and uniform between games, the xbox not so much.

As for going the cheat route, well I was mainly using that for the debugger as the one in the emulator leaves a lot to be desired, I don't want to create a trainer or cheat that has to be loaded in, I want it to be patched directly to the game.
I'm pretty sure I've already managed to isolate the memory area for the pitch and yaw of the camera, I'm only interested in yaw but either way I can see the the address which the value is written to, disabling it simply disables the ability to turn the camera on that axis, just by messing around I seem have found the registers where the values are stored, I can clearly see using a breakpoint that they increase when the camera is turned one way and decrease the other, which is great because if I can just reverse that I'd be in business.

But again, I have no idea how to do that, it's like I have all the information in front of me but it's in a language I don't understand... digital lol.


Anyway I'll check out that gba tutorial just in case I missed something in my approach to this.

[FAST6191]

You can do it with a stock switch (DPDT in this case), people do it all the time
https://vegoilguy.co.uk/reverse_polarity_switching.php https://www.instructables.com/HOW-TO:-Wire-a-DPDT-rocker-switch-for-reversing-po/
Only real tip I have is holes (assuming you want to poke it out) are annoying -- buy a handyman's reamer/tapered reamer and use that to make the hole bigger after you drilled it reasonably close as you can use that to sneak up on the perfect size.
I would probably avoid slicing traces for this (don't know what goes for test points offhand) and bend legs instead if I can or having it free floating is not an option.

If you had a breakpoint it will probably say what instruction did the deed, and while that might have been a simple write then usually a handful back (most breakpoint setups will give you the last 5 or so instructions, if not 10) will be something that generated a value. Figure out how to invert it or send it to the other side of the range if it is not a signed value (if it is say between 0 and 256 then take the value from the max, 256 in this hypothetical, to have the opposite side but equivalent magnitude) for which the X86 without the legacy stuff that is the original xbox should handle happily. Hopefully you can reasonably do it in place rather than having to jump somewhere to do the deed.