This is only ever queried and not set outside of the Core.cpp, so this
should just be hidden internally and just have a function exposed that
allows querying it.
The min-heap provides no ordering when the key is the same on 2
nodes. Disambiguate identical times by tracking the order items
were added into the queue.
Replace adhoc linked list with a priority heap. Performance
characteristics are mostly the same, but is more cache friendly.
[Priority Queues have O(log n) push/pop compared to the linked
list's O(n) push/O(1) pop but the queue is not big enough for
that to matter, so linear is faster over linked. Very slight gains
when framelimit is unlimited (Wind Waker), 1900% -> 1950%]
They all handled it diffrently, so I've just moved it into Advance()
This fixes Pokemon Box booting in JIT/JITIL which shared a bug where
exceptions set in a scheduled event would be ignored untill the next
slice (upto 20,000 cycles).
Events scheduled more than 4.12 seconds in the future (2.96 seconds for
Wii games) would overflow the sign bit and get scheduled in the past
instead, causing them to fire instantly.
Previously GlobalTimer was only updated at the end of each slice
when CoreTiming::Advance() was called, so it could be upto 20,000
cycles off.
This was causing huge problems with games which made heavy use of
the time base register, such as OoT (virtual console) and Pokemon
puzzle.
I've also made it so event scheduling will be accurate to the jit
block level, instead of accurate to the slice.
CBoot::BootUp() did call CoreTiming::Advance which itself blocks on the GPU,
but the GPU thread wasn't started already. This commit moves the SyncGPU
initialization into the Fifo.cpp file and call it after BootUp().
The new implementation has 3 options:
SyncGpuMaxDistance
SyncGpuMinDistance
SyncGpuOverclock
The MaxDistance controlls how many CPU cycles the CPU is allowed to be in front
of the GPU. Too low values will slow down extremly, too high values are as
unsynchronized and half of the games will crash.
The -MinDistance (negative) set how many cycles the GPU is allowed to be in
front of the CPU. As we are used to emulate an infinitiv fast GPU, this may be
set to any high (negative) number.
The last parameter is to hack a faster (>1.0) or slower(<1.0) GPU. As we don't
emulate GPU timing very well (eg skip the timings of the pixel stage completely),
an overclock factor of ~0.5 is often much more accurate than 1.0
Since its lifetime is managed on the CPU thread, this (or a refactoring)
is absolutely required. One of the functions with a PauseAndLock call
added is CFrame::UpdateGUI; this is fine now, since it's called only
after important events happen, so just make sure not to call it every
frame or something :)
We do a whole bunch of non-threadsafe stuff, especially in the UI, and I'm
probably not going to get around to implementing a threadsafe framework
for interaction between the UI and the CPU thread anytime soon. See issue
8220.
Won't work with all games, but provides a nice way to spend extra CPU to make
a variable framerate game faster (e.g. Spyro or The Last Story), or to make
a game use less CPU at the cost of a lower framerate (e.g. Rogue Leader).
This hack is there for quite a long time, and lots of games crashes if it's disabled.
But it's still a hack, so it shouldn't be enabled hard coded. This commit create a new
ini option for this hack which is enabled by default.
Maybe some games does still run very fine without this hack.
