All instances of kMaxPath or MAX_PATH being used have been removed,
and removing this constant is supposed to encourage writing code
without artificial constraints on path length.
In the 'OpenExisting' function, 'open_access' is used to create the flags for opening the file.
However, it is not set to zero, so could end up being incorrect file modes, potentially even emptying the file for appending, which would be bad.
This simply initialises it to zero first.
Previously XexUnloadImage did not cleanup the image fully,
and if XexLoadImage was to be called again on the same module,
it was not initialized fully, leading to a crash when using it.
Search constant table for XMM/float/double data for LoadConstantXmm
Added several fast paths for bitwise and in x64_sequences
Optimized codegen for add-carry
Fixes Xenia not being able to locate unpacked XEXs..
Ideally this should be inside xenia_main.cc though, need to figure out some way to get it working there.
Writing FATX header likely means the game is trying to format it, so we'll help it along by deleting the contents too.
HostPathDevice actually loads in all the file entries when its first inited though, so we also have to re-init the HostPathDevice for the cache partition too :/
If this flag is set there shouldn't be any need to read from the hash tables, we can just read from each subsequent block number.
We'll only trust this flag if the package is read-only (LIVE/PIRS) though, in CON packages we'll always read from hash tables.
This'll try salvaging any corrupt packages loaded in: normally we find the block numbers belonging to a file by reading them from the hash table.
Seems there's some packages out there (eg. Mass Effect 2 demo) that have corrupt hash tables though, so using the block numbers from there just results in a crash.
By verifying the hash of each hash table we can detect if this is the case, and if so we can try just using current_block_number + 1 instead of use any invalid block number.
(we also let the user know about the corrupt table in the log file)
In LIVE/PIRS packages this should hopefully let us get the correct data, since files are usually stored inside consecutive blocks in those package types.
It's doubtful that it'd help much with CON ones though, since those are pretty much a living filesystem.
The older & more used a CON package is, the more likely blocks will be fragmented throughout the file...
Reading from the hash table is the only way to properly read data from these, using current_block + 1 likely won't help much (we'd be going wxPirs-mode, in a way :P)
CON packages do have something that might help with this though: redundant hash blocks, where each hash table is actually made up of two blocks.
Maybe in future we can find a way to automatically use the secondary block whenever the primary one is invalid.
Should let Halo 3 savegames work now (Resume Solo Game...)
This changes XamShowDeviceSelectorUI code to pretty much the same code as xenia-master, with some param checks added from XAM.
Looks like it was 0xB notification which made Halo 3 abort (looks like thats for when storage devices are added/removed)
I guess Halo doesn't like to see that notify just after it was told the device it could make use of?
I reverted the function to master since I don't really think the threading stuff is needed any more.
AFAIK the threads just turned out to be a band-aid fix for the issue in https://github.com/xenia-project/xenia/pull/1417, where games could only ever see a single notification for a given ID.
(Since we'd send the first notify in one thread, then wait a little while before sending in another thread, that'd gave it enough time to see both notifys - but now with the fix from that PR this band-aid isn't needed)
If there's actually any regressions from removing the threading code we can easily put it back in (I'd be really interested in any games that might require this kind of thing too)
The way these functions are handled (and really everything that uses XOVERLAPPED) isn't really correct tho, since they'll cause blocking in the caller thread while it does the work which the actual XAM impls don't do AFAIK.
There probably should be a seperate thread that handles all that, completing the overlapped etc, but I really don't think the way I did it with this band-aid fix was the best way for it...
This fixes Halo CEA putting itself into a packaged/demo mode, where it doesn't perform some DVD checks & skips cache mounting, and probably other things too.
Now CEA should actually mount & write some stuff into the cache dir while the intro cinematic plays
(first writes a pak_stream.s3dpak file, then after a few seconds into the intro video it writes fileList.ps, which seems to have some strange values inside..)
I also added an exception to the code for arcade titles, since they'll probably need to use XamContentGetLicenseMask even when ran outside of a package.
These get stored in different header IDs, 0-31 is inside 0x30000, 32-63 is in 0x30100, and 64+ is probably in 0x30200, etc.
Not sure if any games actually try checking these extended privileges, but hopefully this code should help if any do.
Sega Rally Revo has a weird check for the 0xB privilege, if it's set the game bails out for some reason, a bunch of code doesn't get executed and the game hangs.
Fortunately we can kludge a way around this: the cache code we're trying to influence with the 0xB privilege always seems to check for the 0x17 privilege just beforehand.
The bailout code doesn't, instead it checks for 0xB first and then 0x17 - so we can just add a check to only return true for 0xB once we've already seen 0x17.
This fixes some games (eg. Halo: CEA) not mounting cache.
It seems some games use different SectorsPerClusters values, which then changes the value it expects from NtQueryVolumeInformationFile.
Since we'd always respond with a static value this would make the game think that mounting failed, and it'd bail out of the cache-mounting code.
Now we capture the SectorsPerCluster value when the game writes it to the cache-partition header, and update the NullDevice's sectors_per_allocation_unit with it.
This will make logs more readable and little lighter
Todo: Find out what that register means. It doesn't even have description.
My best guess is that it is used for sync?
Replace a movzx after setae in both ComputeMemoryAddressOffset and ComputeMemoryAddress with a xor_ of eax prior to the cmp. This reduces the length in bytes of both sequences by 1, and should be a moderate ICache usage reduction thanks to the frequency of these sequences.
I'm not exactly sure about amount of parameters,
so I used them from XamContentCreate and it matches quite nicely.
Now Fifa Street returns correct file creation (and it does the file),
but on next run it is corrupted :/
Seems the double-keypress issue was because of XINPUT_KEYSTROKE_REPEAT: Xenia would add that to keyup events, but seems REPEAT is only meant for keydown (well SR1 treats it as a keydown event at least)
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?
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
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.
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?
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)
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
gibbed