Couldn't find a way to get bitfields & byte-swapping to play well together, so this was the best I could come up with... at least the proper version numbers will show in the log file now :)
This should be safe to do hopefully, most errors happen before any part of the XEX is modified, and the errors that can happen after modification should be very rare/impossible thanks to the earlier checks.
It might be good to write up some way to revert any changes though...
Happy new year! Here's my first commit of the 2020s :)
With these fixes, Halo 3 Epsilon will now write cached map data & other things (autosaves/datamine...) to the cache0/cache1 partitions, (as long as mount_cache cvar is set)
(Halo 3 retail will also write some things to cache with this, but oddly doesn't cache map stuff... which is strange because Epsilon was built only a day or two after the retail build, so I'm not sure why it'd work differently...
Maybe retail needs a TU applied for it to work or something like that)
Other games should hopefully work with cache now too (AFAIK the problem was in SDK library code, that a lot of games probably share)
No idea if this will actually improve anything though, but at least things will work closer to what games expect :)
The way this works is by tricking the cache-partition code (staticly linked into the game exe) into thinking that the Partition0/Cache0/Cache1 devices are valid.
To do that I made another kind of VFS device, the NullDevice, which just takes in a list of paths to handle.
Whenever an IO request is made to one of these paths, the NullDevice can simply pretend to the game that everything was successful, which satisfies the requirements needed for caching.
It also makes use of another trick: setting TitleInsecureCacheDrive XEX permission, which seems to skip a huge chunk of cache-init code (STFC filesystem device registration & stuff like that)
I'm not sure if this would work with every single revision of the STFC/cache code though...
At least in Halo 3 the retail code will handle the TitleInsecureCacheDrive case for us fine, but maybe older/more recent versions don't include functionality for it, need to look into it some more.
(I did try an impl. without needing this permission months ago, got pretty far with it but got caught on one tiny issue that I couldn't figure out... too bad I didn't find out about this permission earlier!)
threaded UI notifications from emoose Issue 1296
added fixups for hdd detection in more games (wheelman for example)
changed filter that stops notification spam
Formatting fixes.
Add comment about SSE2 builds not working on non-AVX(2) CPUs.
Don't build tests.
Prepare artifacts:
Switch to PowerShell.
Rename xenia.exe to xenia-canary.exe.
Add Releases:
This allows GitHub Actions to have a link to the latest artifacts like AppVeyor, except not slow as fuck.
Currently AVX-only since users will get confused which one to download (this is also why vfs-dump isn't included in the zip), and I don't know how to use the upload_url from another job configuration.
Releases won't be created for PRs.
You can download the latest Release from here: https://github.com/xenia-canary/xenia-canary/releases/latest/download/xenia-canary.zip
New cvar clock_source_raw allows to use the cpu cycle counter itself as an alternative time source, if system timing resolution is to low and causes problems.
- Removed tick and time values from ThreadSavedState.
- Removed affiliated get/set code from Save and Restore.
- Removed dangerous SetGuestTickCount method.
This fixes cases introduced by 52e836d0f81e752ba368717e68773b591adfa9cf
where thread handles get closed before the thread finishes.
Handle was assumed to be alive there, which was not true as
threads self-referenced only their objects, not their handles.
Affected games: Payday 2 Demo
Although this seems counter-intuitive, operating on handle
reference counters in
- ObLookupThreadByThreadId
- ObReferenceObjectByHandle
- ObDereferenceObject
allows to cleanly clean up handles for resources created elsewhere
and destructed by ObDereferenceObject (for example, threads with 0x80
creation flag). Operating on pointer reference counters alone
would leave a stray handle in the slots list.
Closing the thread handle should delete the thread object
if it's finished. When this handle was retained, closing the handle
left a lingering handle reference and thus this XThread would leak
Cancerous