- Define more of the PPC structs
- Use custom enums instead of recycling libcurl's which aren't guaranteed to match.
- Move host curl state out of the PPC structs
- Use cafeExportRegister instead of deprecated osLib_addFunction
SysAllocator<> would allocate at Cemu boot and then never release memory.
Now we have CafeStaticVar<owner, type, count> which is explicitly allocated/deallocated via the owner and can be tied to COS/IOSU module lifetime. This also works as an automatic reset when relaunching emulation.
If the command buffer was still empty, it wasn't replaced with a bigger one when a command didn't fit since it checked if it was smaller then the entire command pool, not the command buffer size itself.
The address relocator was basically fine with addresses up to 8MB within a code cave, but the size was capped to 1MB. So you could overwrite the next group's code cave if it was too big.
Cemu fired the alarm right away instead, so a handler which sets its alarm again with a delay of zero looped forever. nsyskbd does this with a key repeat rate of zero.
OSSetPeriodicAlarm likewise ignores a period of zero or below.
Leaving recompiled code now jumps straight to the exit code, instead of faking a call on entry that we can "ret" to later.The old solution basically never branch predicted the path (if I measured it correctly) on my AMD CPU.
It also removes the _controlfp calls with an MXCSR instrinsic that would additionally set the (potentially unnecessary?) x87 FP state, which we don't need.
Entering and leaving recompiled code used to cost ~32 ns (though it was a benchmark, so take it with a grain of salt). The jump change saves ~4 ns and the MXCSR lowers it by ~22 ns, bringing it down to ~6.5 ns total.
Noticed this when Cemu releases started including loud audio buzzing after I did a Visual Studio update. Seemingly it messed with some of the AX mixer code across PPC callbacks, though quite likely that some other places were affected too.
This was found to be a fix for Cars 3's showing a black screen. Might be applicable to similar games made with the engine, such as Disney Infinite, though it has yet to be tested. At least Cars 3 uses the texture readback in some kind of dynamic exposure system.
I think its decently niche enough to not really cause a huge performance bottleneck.