Exclude subdirectories of docs and .github;
This fixes GitHub Actions triggering Azure.
Remove unneeded cd commands.
GitHub Actions:
Use shorter version numbers.
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...
illusion98