The AI controller has been reworked to be made independent of the audio
plugin. All it expects is 2 callbacks (one for setting sample format,
and the other to push samples).
A retro-compatibility module implements these 2 new callbacks using the
existing audio plugin in a best effort manner as pure zilmar spec
is not fully compatible with the new callbacks. However, by exploiting
implementation details of both core and audio plugin, we can get
a "good enough" implementation of these callbacks.
Audio DMA fifo has been also reworked and its associated data has
changed. A compromise has been made in order to not change the
savestate format.
reset_hard is not called that often, so it is not that important to
save cycles with an optimisation that could, as the comment seemed to
imply, cause a memory leak.
This commit cleans up checks like the following in recomp.c:
if (r4300emu != CORE_PURE_INTERPRETER && ...)
which became unreachable after the Pure Interpreter got its own opcode
dispatcher instead of forwarding everything to the Cached Interpreter.
This commit gives the Pure Interpreter its own opcode dispatcher. It
uses a switch statement to parse major and minor opcodes, then uses an
opcode's fields to kill writes to integer register 0, and gives whole
opcodes to interpreter functions for them to figure out what to do.
MFC0, MTC0, J, JAL, JALR, and the integer memory access instructions,
L* and S*, still used members of the Cached Interpreter's pre-parsed
instruction structure via 'PC->...'. They have been replaced with the
macros in macros.h (irt, rrd...), which the Pure Interpreter now uses
to parse opcode fields.
The new dispatcher decodes one opcode ahead only if the active opcode
is a jump with a delay slot. It also correctly handles killing jumps
that target themselves with a NOP (binary all-zeroes) in their delay
slots.
This should allow for some flexibility in the choice of the controller
input and rumble output.
For now, we keep the old behavior and use the input plugin, but other
input source and rumble sink could be considered.
We hardcode te connection in the core, but ultimately,
the choice of an external controller/rumble should be the responsibilty
of the frontend.
This should allow for some flexibility in the choice of a time source.
For now, we keep the old behavior and use the C localtime, but other
time source could be considered.
Furthermore, we hardcode the connection in the core, but ultimately,
the choice of an external time source should be the responsibility of
the frontend.
- Consistency in the calculation/recalculation of CurrentFPSTime
and ThisFrameDelta
- Clearer VITotalDelta increment
- Declare/assign persistent variables in consistent order
CurrentFPSTime and ThisFrameDelta must be updated together.
The bug created an audio latency of 1/4 - 1/2 second in mupen64plus-ae.
The core was not slowing down enough to let the audio catch up.
