Recently we have been getting some requests to make the existing vsync
setting available in the Android GUI:
https://bugs.dolphin-emu.org/issues/13650https://forums.dolphin-emu.org/Thread-vsync-toggle-for-android
I don't quite understand why enabling the vsync setting is helpful when
Android already enforces vsync, but I guess having the option available
doesn't hurt. I'm putting the setting under Advanced, unlike in
DolphinQt, since there's no clear reason why the typical user would want
to use this setting.
Fixes LIT (https://bugs.dolphin-emu.org/issues/13635). The text does not include normals, but has lighting enabled. With the previous default of (0, 0, 0), lighting was always black (as dot(X, (0, 0, 0)) is always 0). It seems like the normal from the map in the background (0, 0, 1) is re-used.
LIT also has the vertex color enabled while vertex color is not specified, the same as SMS's debug cubes; the default MissingColorValue GameINI value of solid white seems to work correctly in this case.
No need to materialize the immediate if it is zero, we can just use WZR.
Before:
mov w27, #0x0 ; =0
str w27, [x29, #0x1178]
After:
str wzr, [x29, #0x1178]
Many games call GXSetGPFifo() without first waiting for the GP to finish
consuming outstanding commands in the previous GP fifo. Normally,
Dolphin runs OpcodeDecoding in 1000-cycle time slices. In that time
frame, GXSetGPFifo() has probably completed and the GP read pointer now
points to entirely new memory. If the last GP fifo copy ended in an
incomplete command, the new GP fifo would most likely desync for a
while. To avoid all this, give the GP a time slice right now to copy the
remaining data from the previous GP fifo.
Indexed XF loads specify the number of 32-bit words (generally floats, but light data has some integers) to load, not the number of bytes. This was only a mistake in the fifo analyzer text; the actual implementation already loaded words.
The light LIT fifolog from https://bugs.dolphin-emu.org/issues/13635 has position data at physical address 11ae3180. This works fine when using the memory viewer in physical mode, but the corresponding virtual address (91ae3180) previously didn't show anything in effective mode. It works fine now though.
This shouldn't affect playback of fifologs as everything in there uses physical addresses; this only impacts the memory viewer.
This logic was copied from CBoot::SetupBAT.
