Open emoose opened 4 years ago
Neat but not really that Xenia related: seems SR1 still has the dev console in the game!
Setting the byte at 0x835F4C3E (TU1) or 0x83710223 (no-TU) to 1 opens it (add 0x100000000 to offset if editing with CE), typing doesn't seem to work in Xenia atm sadly, but I'd guess on a real X360 you might be able to plug in a keyboard and type stuff.
There's a ton of commands still in here too, the devs also did a stream where they showed off some, so you could probably copy them from there. (E: looks like a bunch of the ones they showed off aren't in the retail build though sadly :( maybe someone could hack them in)
EDIT: hehe https://sendvid.com/08efdkz4 :)
E2: In case anyones interested in the XEX patch needed (and so I don't lose it), here it is for TU1:
8265F694 48 00 0A A4
82660134 48 0B 8E F9
82660268 48 0B 8E 14
This mods the UpdatePad func to branch to UpdateKeyboard straight after it, and changes the save/rest calls in UpdateKeyboard to match UpdatePads (since we're branching just before UpdatePads epilogue, to just past UpdateKeyboard's prologue)
NOTE: I'm not really sure if you can apply the patches above with CE when using xenia, best bet would probably be to apply TU1 xexp to no-TU xex with xextool, then change patched xex to unencrypted/uncompressed (xextool -eu -cu default.xex), and then patch the xex with a hex editor.
Without this all the code for updating keyboard etc is still there, but just goes unused. You'll still need to change the byte I mentioned above to actually get the console to open though, since I guess the code for checking console key binding was stripped with the UpdateKeyboard calls.
Before anyone starts wondering, SR2 retail sadly has all the console/keyboard code removed, didn't bother checking any others.
Should this get a gpu-corrupted-drawing label?
No.
Tested on https://github.com/xenia-canary/xenia-canary/commit/293e9582ec35d30ef17a25f08858a82eed945f69
Intro, menus and cut scenes work without problems. (Except for some menu items, read below).
The first time I tested without protect_zero=true parametr(Xenia-canary-config), the game starts, intro, menu. You can start a new game, but if you don’t do anything for a long time, or if you manage to get in and go into the game, then after a couple of seconds the emulator breaks. (Guest Crash, or Graphic device lost) (1-6 pictures). (Log №1) The second time I tested with protect_zero=false, Big-big Thanks!!! @emoose for debugging finding and description problem (Read above). The game works perfectly, without crashes. After a long time of the game, no errors were noticed. Saving and loading - work well.(Log №2\3). Sound works fine. (7-10 pictures) (Log number 2) I also want to note that there are two errors in the game: The first one is the emulator freezing when you go to the settings (Screen, Sound, Control), only restarting helps. The second one is sometimes if you twist the camera there is no sky texture, or maybe another texture (It turns black). (Log №3. Also in this log is checked the operation of save and load). I think now game can get the status - playable.
Log_1: xenia.zip
Log_2: xenia2.zip
Log_3: xenia3.zip
state-playable, gpu-missing-drawing, tech-middleware-havok
Definitely going to get some flack for bumping such an old ticket asking to get spoonfed more or less, but here goes....
Neat but not really that Xenia related: seems SR1 still has the dev console in the game!
Setting the byte at 0x835F4C3E (TU1) or 0x83710223 (no-TU) to 1 opens it (add 0x100000000 to offset if editing with CE), ~typing doesn't seem to work in Xenia atm sadly, but I'd guess on a real X360 you might be able to plug in a keyboard and type stuff.~
There's a ton of commands still in here too, the devs also did a stream where they showed off some, so you could probably copy them from there. (E: looks like a bunch of the ones they showed off aren't in the retail build though sadly :( maybe someone could hack them in)
EDIT: hehe https://sendvid.com/08efdkz4 :)
E2: In case anyones interested in the XEX patch needed (and so I don't lose it), here it is for TU1:
8265F694 48 00 0A A4 82660134 48 0B 8E F9 82660268 48 0B 8E 14
This mods the UpdatePad func to branch to UpdateKeyboard straight after it, and changes the save/rest calls in UpdateKeyboard to match UpdatePads (since we're branching just before UpdatePads epilogue, to just past UpdateKeyboard's prologue)
NOTE: I'm not really sure if you can apply the patches above with CE when using xenia, best bet would probably be to apply TU1 xexp to no-TU xex with xextool, then change patched xex to unencrypted/uncompressed (xextool -eu -cu default.xex), and then patch the xex with a hex editor.
Without this all the code for updating keyboard etc is still there, but just goes unused. You'll still need to change the byte I mentioned above to actually get the console to open though, since I guess the code for checking console key binding was stripped with the UpdateKeyboard calls.
Before anyone starts wondering, SR2 retail sadly has all the console/keyboard code removed, didn't bother checking any others.
The addresses in Xenia have changed since this post (gee, go figure) Also, no matter how I apply the TU to my xex and uncompress and unencrypt it via XexTool, those offsets don't exist.
i finished the game , to me the game can be "playable"
playable from start to finish with these settings:
apu_max_queued_frames = 16
(Stops the audio delay)
protect_zero = false
(Stops the game from crashing)
state-playable, requires_protect_zero_false
Marketplace
Tested on https://github.com/xenia-canary/xenia-canary/commit/e75d0f155487f160d52022e50a9ad5b965667591
Issues:
Game starts fine, no graphical issues - after a few seconds in-game a guest crash occurs though. Seems to be because game tries writing to 0x40 - using --protect_zero=false allows the write to go through & stops guest crash from happening, but I'm pretty sure if it tried that write on an actual X360 it'd crash...
Nopping out the offending instructions causes graphics to get a little wacky, so I guess the offending code is graphics related.
I guess we need to find why it's trying to write to 0x40, that address is probably (some pointer + 0x40), with the pointer being 0 for some reason...
TU1 causes crash during intro movies, seems to be because of a call to NetDll_XNetQosServiceLookup - that func would populate some pointer param on X360, which TU1 tries reading some data from during load. Editing NetDll_WSAWaitForMultipleEvents to return non-zero lets it skip this read, but that's not a proper solution of course, really we should update NetDll_XNetQosServiceLookup to alloc some mem and fill the pointer properly. (EDIT: TU1 crash should be fixed in https://github.com/xenia-canary/xenia-canary/commit/911920a5366d4de9dddf20735be8367680f05e64)
Log:
xenia-noTU.zip (no-TU, guest crash after chara customization)
Screenshot(s):
Wacky graphics after nopping out guest-crash instructions (the colors here change every frame):
Labels:
state-crash-guest state-gameplay