This removes explicit checks sprinkled all over the codebase to instead
just have the SW rasterizer expose an implementation with no-ops for
most operations.
* IncomingDisplayTransfer: Triggered just before a display transfer is performed.
* GSPCommandProcessed: Triggered right after a GSP command is processed.
* BufferSwapped: Triggered when the frames flip
This is exposed in the GUI as a new "CiTrace Recording" widget.
Playback is implemented by a standalone 3DS homebrew application (which only runs reliably within Citra currently; on an actual 3DS it will often crash still).
Changing it makes emulation inherently inaccurate. It also had a wrong
default value (30, whereas the real system has a refresh rate of 60 Hz)
which, even if changed, would continue to be used unless people manually
removed it from their config files.
memory.cpp/h contains definitions related to acessing memory and
configuring the address space
mem_map.cpp/h contains higher-level definitions related to configuring
the address space accoording to the kernel and allocating memory.
It is used to downscale the input image horizontally and vertically, previously we were only downscaling it vertically so this caused a hard-to-debug memory corruption problem.
Bit 3 is used to specify a raw copy, where no processing is done to the data, seems to behave exactly as a DMA.
Bit 1 is used to specify whether to convert from a tiled format to a linear format or viceversa.
Display transfers with the horizontal downscaling flag were calculating
the wrong output size, causing them to write double the amount of data
intended. It is likely that this was perceived as correct due to a
separate bug in calculating source indices which caused the image to be
padded unless the previous bug was present.
This fixes both issues, correcting flickering issues in 3dscraft,
blargSnes and more (caused by the transfer overwriting the back buffer
which followed) as well as potentially fixing other crashes.
PDC0 and PDC1 are both VBlank interrupts. PDC0 was being treated as a
HBlank interrupt and fired many more times than it should. They now both
fire together at 60 Hz. This puzzlingly *improves* apparent framerate on
many applications.
A few other interrupts were being fired inside the GSP command
processing instead of on the actual GPU register writes, so they were
moved there, which should cover direct writes tho those registers not
going through the GX command queue.
It's not really known how this actually works. Some testing has shown that this probably performs no filtering, and common usage in games suggests it's not actually resizing the image at all.
However, this patch does seem to fix some homebrew showing quasi-duplicated images while still keeping other applications in a working state.
