Commit Graph

5772 Commits

Author SHA1 Message Date
Margen67 9842eca65d Comment out Azure badge 2020-02-19 03:36:12 -05:00
emoose 0f657551bc [XAM/HID] Add more support for keyboards & fill in unicode member of keystroke
CoD4 requires the unicode member to write text into the dev console, Win32's ToUnicode function seems to work fine for this.
Xam functions have been updated to support keyboard devices too, which *should* let CoD4 detect the keyboard and let you use it to open console etc..
Seems the XEX still needs a 1 byte patch for it to work tho :( no idea why, does keyboard work on actual X360 without any patching?
2020-02-19 03:36:12 -05:00
chss95cs@gmail.com d745905128 Added lea based multiply optimization for pow2+1 values below 16. Added magicgu2 division magic number optimization for INT_64 and INT_32. Added in my HIR optimization subpass but disabled all but 3 of the optimization rules. 2020-02-19 03:36:12 -05:00
emoose e892005562 [XAM/User] Only set buffer_size if it's too small
CoD4 calls this with a huge 0x4000 buffer, and then if the buffer_size returned is any smaller it asserts & stops running...
Need to check if this is actually how it should work, but this should help get some CoD4 running
2020-02-19 03:36:12 -05:00
emoose db8d47b2c3 [HID] Add keyboard_keyup cvar (default true) since dash needs keyups to work properly
Made this a cvar since SR1 will double-press when it sees both keydown & keyup, strange.
2020-02-19 03:36:12 -05:00
emoose ab74392664 [XAM/HID] Add keyboard_passthru cvar, allows XInputGetKeystroke to receive proper keyboard events
Maybe useful for debug games, or games modded to allow in-game consoles.
2020-02-19 03:36:12 -05:00
emoose 4f1836aa77 [XAM] Update XNetQosServiceLookup with actual XNQOS struct
Taken from the xboxstubs.h file linked just above it.
2020-02-19 03:36:12 -05:00
emoose 51115fa6f7 [XAM] Better stub for XNetQosServiceLookup, add XNetQosRelease
Based on the NetDll_XNetDnsLookup code, this should fix Saints Row TU1 trying to access the QoS data even though we returned an error.
2020-02-19 03:36:12 -05:00
emoose 7420d76070 [App] Add cache: -> \Cache0 symlink
I think this should be safe to do, seems games will only make use of either cache:, or cache0: & cache1:, not both kinds, so shouldn't be any risk of conflict.
cache: might only be used in older SDK cache code, at least so far I've only seen it used in the older Halo 3 Beta build.
2020-02-19 03:36:12 -05:00
Nathan ca2f6ff588 [Git] Added /cache0/, /cache1/, and recent.txt to .gitignore 2020-02-19 03:36:12 -05:00
emoose 4cbdeb5a94 [XAM] Load SPA achievement data from DLC content if it exists
This'll load in and convert the SPA data from the spa.bin inside DLC (marketplace / 00000002) content, into the profile GPDs.
(note that changes from the new SPA won't show in the log-file achievement list until game is restarted!)
Also fixed some minor log bugs to do with endianness...

The existing SPA code should make sure only additions from the SPA are loaded in, eg. achievements that were added - achievements that might be missing shouldn't make any difference.
e.g. it should be able to perform a load like:
  base game (20 achievements) -> DLC2 (50 achievements) -> DLC1 (30 achievements)
and the final GPD will contain the 50 achievements, from the SPA which contained the most.

Only additions from new SPAs will be loaded, any achievement changes (like a description text change or something) won't have any effect.
Not sure if we should try adding things to support that or not...
I'd guess that the X360 would probably support it, but if there isn't anything that takes advantage of it, is it worth us supporting?
2020-02-19 03:36:12 -05:00
illusion98 c66c43f570 Add commit number 2020-02-19 03:36:11 -05:00
emoose cd56d48130 [VFS] Some more STFS code improvements
Reverted to older BlockToOffsetSTFS code (with some improvements, now named STFSDataBlockToBackingBlock)
Split the To*Offset functions into ToBackingBlock & To*Offset funcs, for later use when we need the actual block numbers instead of the offsets.
Store the num blocks per hash table & block step count in the device instance, instead of calculating it each time.
Add read_only_package() & root_table_secondary() getters to the STFS descriptor struct (note: will be replaced with better stuff once stfs-headers is eventually merged)
2020-02-19 03:36:11 -05:00
Gliniak 042a820ae0 [XAM/Party] Added stub for: XamPartyGetUserListInternal
It will allow to run dashboard with signin_state = 2

Should we create different xam file for XamParty functions?

ToDo: Finish struct that store user info
2020-02-19 03:36:11 -05:00
emoose 0553575ee1 [VFS] Add some STFS magic numbers, skip hash table checks for read only packages 2020-02-19 03:36:11 -05:00
emoose 428f554cf3 [VFS] Fix GetHashEntry for level 2 entries... 2020-02-19 03:36:11 -05:00
emoose e1053938eb [VFS] Fix BlockToHashBlockOffset's level 2 case (blockStep0 -> blockStep1)
& changed code to switch statement instead.
2020-02-19 03:36:11 -05:00
emoose e4b326667d [VFS] Improve STFS GetBlockHash function - now gets hash from correct hash table.
This should hopefully allow Xenia to be more compatible with larger / more made-use-of profiles.

Each hash table actually consists of two hash tables for redundancy, which table is used is decided by the hash table level above it.
Previously there was some code to try swapping which table to use if a flag isn't set, but the code ended up being commented out & unused...

After looking at some other X360 mod tools sources I've managed to come up with this solution, which visits each hash-level it can to retrieve the correct table number to use.
Really this is probably a little inefficient, the code I based this on would actually cache each table in memory to make these visits a lot quicker, maybe should look into doing the same here.
For packages with read_only_package() == true, this maybe isn't even necessary too - but it's probably worth keeping it as-is just in case though.
2020-02-19 03:36:11 -05:00
emoose e56ea2b81c [XAM] Add some proper error codes to a few XamUser functions
It might be worth finding games/apps that use these functions and see what error codes they check against...
2020-02-19 03:36:11 -05:00
emoose 3a904987b2 [XAM] Simplify XamShowDeviceSelectorUI, update an old device ID
Storing the content type inside the device ID from DeviceSelectorUI shouldn't be needed now.
AFAIK it was only used so that we could extract it later inside XamContentGetDeviceData, but that wasn't actually how GetDeviceData was meant to work.
2020-02-19 03:36:11 -05:00
emoose 51e4af5430 [Kernel] Fix wide-printf functions not processing %ws format correctly
This would break strings like memory://%.*ws, because the %ws would set FF_IsWide, but FF_IsWide is actually treated as an "is opposite encoding" flag.
Since the function is already wide, that flag would make it think it's opposite encoding and it'd try reading the param as ASCII instead of Unicode...
2020-02-19 03:36:11 -05:00
emoose 9b3ef10f21 [Kernel] *FormatData: make peek() match get() endian, fix skip() not advancing pointer 2020-02-19 03:36:11 -05:00
Gliniak 958a9bfa29 Removed useless file that survived rebase 2020-02-19 03:36:11 -05:00
Gliniak 24cba2e720 [Log] Added information about implementation state 2020-02-19 03:36:11 -05:00
Gliniak e34186d3fe Revert "[XAM/User] Added title_id == 0 check for few User functions"
This reverts commit 05433007c5.
2020-02-19 03:36:11 -05:00
Gliniak c7845f1717 [XAM/User] Added title_id == 0 check for few User functions
Games like to report title_id as 0 (it is expected behaviour).
0 in this case means currently opened title
2020-02-19 03:36:11 -05:00
Gliniak cc594dae40 [GPU] InitializeRingBuffer - Clear buffer space to prevent random data readout 2020-02-19 03:36:11 -05:00
emoose 0a9e9e0aab [XAM] Add XamShowCreateProfileUI & XamProfileCreate impl.
Seems to kinda work, xshell uses XamProfileCreate and says that it's successful at least.
Dash uses the ShowUI function, but doesn't seem to login to the created profile correctly for some reason... restarting with the toml configured for the new profile does seem to work though.
2020-02-19 03:36:10 -05:00
emoose 4d3aff25d0 [VFS] Oops, fix wrong BlockToOffset result for non-CON packages 2020-02-19 03:36:10 -05:00
emoose d2edb53282 [Kernel] Fix XamReadTile not returning profile pic, breaking dash profile...
This caused dash not to load profile anymore, since dash passes user_index == kNone...
The new method should be closer to how things are actually meant to work.
2020-02-19 03:36:10 -05:00
emoose 18c930c1b2 [VFS] Port new BlockToOffsetSTFS algo from stfs-headers
65ca664fdb
This should give better compatibility with CON packages - ie. profiles taken from actual consoles should hopefully extract properly without errors, now there's shouldn't be any need for extracting them with Velocity/Horizon first.
2020-02-19 03:36:10 -05:00
emoose d934bccac5 [XMP] Add extra checks from XAM to help prevent dash host crash 2020-02-19 03:36:10 -05:00
emoose 50f0c6db19 [User] Add some extra checks from XAM to Read/WriteProfileSettings exports 2020-02-19 03:36:10 -05:00
emoose 6db428b24e [XAM/User] Fix wrong error code given when ReadProfileSettings buffer is too small
Strange, seems ReadProfileSettings returns this error as the result code instead of the xoverlapped error code - it could be possible other Xam functions do the same too.
This fixes Crackdown loading (thanks Gliniak for the tip about buffer size), hope it doesn't break any other games though.
2020-02-19 03:36:10 -05:00
emoose a7e1be2bb9 [XAM/User] Fix dashboard GPD overwrite when loading new game 2020-02-19 03:36:10 -05:00
emoose f638037fa2 [XAM/User] Allow titles to actually access title-specific settings
Would only allow access to dash GPD previously...
I'm not sure if we need to setup the XPROFILE_TITLE_SPECIFIC settings in advance or not though, really it should be on the games to do this themselves, but not sure whats actually needed...

This should probably fix games that would save progress to profile (Halo 3 progression, etc.), haven't actually noticed any changes myself yet though.
2020-02-19 03:36:10 -05:00
emoose 8ec3407e4c [User/XAM] Oops, fix null pointer deref 2020-02-19 03:36:10 -05:00
emoose 203dcb28be [XAM/User] Try logging in to any available profile when XUID isn't set
Now the XUID doesn't need to be set at all for Xenia to try logging into an available profile (as long as signin_state != 0, previously this needed XUID to be set to '1')

So from a default install, you should be able to just drop an X360 profile into the right profiles dir, and when you run Xenia it'll login to it automatically for you, no config changes needed!

This applies to all 4 user slots, just set their signin states, drop 4 profiles in and it should log them all into each one seperately, then you can edit the config with specific profile XUIDs for each user.

Xenia should now only generate a default XeniaUser profile when no profiles are available for a user.
2020-02-19 03:36:10 -05:00
emoose 6e4ed5b333 [XAM/User] Add UserIndex enum, handle special UserIndexes inside KernelState::user_profile 2020-02-19 03:36:10 -05:00
emoose 73342e6d62 [XAM/User] Add support for multiple signed-in users/profiles
This adds support for multiple profiles to Xenia, profiles can be configured with the [Profiles] user_*_xuid / user_*_state config settings.
If state is non-zero (1 = offline, 2 = LIVE), the profile will be counted as logged-on - either with a generated XeniaUser gamertag, or if the XUID is set to 1 the first available profile will be loaded.
The XUID can also be set to the offline-XUID (E000...) of an existing profile, to sign in the user as that profile.
(Profiles should be stored in the Xenia content/FFFE07D1/00010000/ folder, either as an STFS package or an extracted folder)

All the XamUser* functions have been updated to support multiple user_index's provided to them too.
(there's still issues with weird indexes like 0xFF, 0x7FF9... being given though, still dunno what's with that, the KernelState::user_profile() code will treat 0xFF as 0)

I'm not really sure if this is the most ideal way to do things though, but it does appear to work fine, at least Halo 3 does detect the profiles with state > 0 fine.

TODO: look into changing up xam_content to make use of user_index & profiles.
It shouldn't be too difficult now to emulate the same content paths X360 uses (seperating content by XUID etc)
Would probably be a good idea, since it'd probably be needed for us to support multiple profiles properly, so that they don't all share savegames etc...
2020-02-19 03:36:10 -05:00
emoose 0a97e3b576 [HID] Allow winkey driver to use the first unused user index
This removes the user_index == 0 requirement from the InputSystem code, and updates WinKeyInputDriver to use the first non-connected user index if it can.

Eg. if you had 2 XInput controllers plugged in, those two will take up user index 0 and 1, and keyboard will take user index 2.
If all four indexes are taken up already, the WinKey driver will be disabled.

(This is done by passing already-setup drivers to each drivers Setup function: since WinKey is the last to be setup, this'll let it query the XInput driver and find which user_index it should handle)
2020-02-19 03:36:10 -05:00
emoose eef370645e [Xam/Content] Remove unused ResolveGameUserContentPath func
(not needed since we store this stuff inside GPD now)
2020-02-19 03:36:09 -05:00
emoose 58742cb2e6 [XAM] Allow loading profile from STFS (extracts package automatically!)
Profiles can now be placed as either an extracted folder with GPDs, or an STFS package, inside the Documents\Xenia\content\FFFE07D1\00010000\ directory
eg. Documents\Xenia\content\FFFE07D1\00010000\E0000E07FA53D7F1
(this roughly matches the same location as X360 stores it)

If loading an STFS package the package will first get extracted to <path>.dir/, and then the profile is loaded/saved into that directory.
(originally was going to mount the package and read everything in-memory, but then realized how hard adding new files/modifying/etc would be.. VFS doesn't allow mixing two devices into the same mount_path afaik)

Code for extraction is taken from xenia-vfs-dump (as StfsContainerDevice::ExtractToFolder)

A [XAM]profile_xuid config option is added too, which should let you pick which profile to load from the FFFE07D1\00010000\ folder if you have multiple there.
(at least I hope it should - something like "profile_xuid = 0xE0000E07FA53D7F1" will work I hope... cpptoml might have issues with hex digits though, not sure, will investigate later...)
If profile_xuid isn't set (left at -1), Xenia will just load whatever the first file/folder inside there is.
2020-02-19 03:36:09 -05:00
emoose e6c9577866 [Base] Change DEFINE_uint64 -> DEFINE_int64, cpptoml seems to have issues with uint64..
Tried setting a uint64 setting to -1 (FFFF FFFF FFFF FFFF), which made it throw a out of range exception when loading the toml...
Internally it uses int64 to parse numbers, so I guess it doesn't work well with converting to uint64?
Changing everything from uint64->int64 seems to solve it though, now -1 works fine.
2020-02-19 03:36:09 -05:00
emoose df40ed6ea4 [VFS] Fix STFS file table info being read in wrong endian 2020-02-19 03:36:09 -05:00
emoose 7e6e02e685 [XAM/User] Fix AchievementPlatform definitions...
big oof
2020-02-19 03:36:09 -05:00
emoose 85b8fa0177 [XAM/User] Store profile inside content root instead of next to EXE
eg. Documents/Xenia/content/profile/
2020-02-19 03:36:09 -05:00
emoose 7098c37969 [XAM/Misc] Impl. IsSystem/IsXbox1/IsSystemExperience & FirstRunExperienceShouldRun exports 2020-02-19 03:36:09 -05:00
emoose 819e9e1391 [XAM/User] Only add arcade games to profile if license_mask is set 2020-02-19 03:36:09 -05:00
emoose 7b721aa59a [XAM/User] GetTitleId -> GetTitleData, check flags/titletype before adding to profile 2020-02-19 03:36:09 -05:00