Only remaining issue is that clicking on the titlebar of the window, to give it focus, is already interpreted as input. But clicking on the window in the task bar, or using alt tab works to get back, without causing an input event.
The old implementation always polled the local 1st Wiimote and used that as input for the Wiimote that is mapped to the player. But the reporting mode for Wiimotes can be different, even when using the same extensions. So an input for Wiimote 1 with a data size 4 could be used for Wiimote 2, which actually requires data size 7 at that time for example.
The 2nd problem was that the code added a dummy input into the buffer, when the reporting mode changed. But when the data from the other player hasn't arrived yet, the data in the buffer is out of order. Well, i think this is the problem, i'm not 100% sure, because i don't fully understand how the buffer works. But on the other hand, i'm pretty sure this will just force sync the players on reporting mode changes, instead of allowing them to be apart.
Pros:
- No more desyncs caused by big bugs in the code.
- Can use different extensions for different players.
Cons:
- Higher latency, because instead of polling 1 controller per player at once, all controllers are polled in order, send to the other players, before the next is processed.
- Have to setup the Wiimote, which the player is going to use, instead of the 1st one.
Now, if the controller config could temporarily be overridden with the one from another slot, the 2nd problem could be fixed. But at the same time, we would lose the ability to use different extensions. (unless we hack around it somehow, or properly send the used extension to the other players)
Before this variable was an u8, which could theoretically result in desyncs with a large buffer(greater than 255*120/200=153) filled with blank inputs. If this could actually happen, i don't know. But this part of the code on its own looks like it could break.
A static var is not a good idea, when the value needs to be reset for every session. Also, the variable holds the data size, so it makes sense to set the data size, where the data is added.
On master, when polling the 1st in-game controller, Dolphin would poll all the 1st local controllers. With the 1st commit, each client waits its turn, which would dramatically increase the lag.
Now with this commit, it even polls all local controllers at once, so it should have even less latency than master in a few setups. Like one player with 3 controllers and the 2nd one with just one controller.
This fixes issues with setups like:
Player 1 uses port 1 and player 2 uses port 3, or
player 1 uses port 2 and player 2 uses port 3, so nobody uses port 1
Disclaimer: I can't test if this works on xbox one controllers, i don't have one. But i have conformed that this UpdateMotors() is related to rumble for emulated wiimotes.
This partially reverts commit "XInput: Apply immediately as well" (1958a10b6f) from pr # https://github.com/dolphin-emu/dolphin/pull/1560
Hopefully this fixes the xbox one controller rumble issue:
https://bugs.dolphin-emu.org/issues/9071
And in theory it might reduce the used usb bandwidth, as it was originally intended before pr 1560.
@JMC47: Please do a good amount of testing, to see if this breaks rumble for wiimotes or gamecube controllers emulated with xinput devices.
This is an oversight from pr https://github.com/dolphin-emu/dolphin/pull/3266 . Thanks to degasus for pointing this out.
It's possible that MAX_TEXTURE_BINARY_SIZE can be optimised, but i wanted to play it safe considering the 5.0 stable release.
I'm not entirely sure what is happening, but this optimisation is causing an issue in Sonic Riders: Zero Gravity. Apparently the issue would also be fixed by PR#3747, but this PR should also fix similar issues.
Games that use partial updates might get slower with this, so some performance regression testing would be nice. Games like New Super Mario Bros, RS2, Zelda TP and Silent Hill. Testing with high graphics settings makes sense, since this would mostly end up in more work for the GPU.
- remove an outdated comment about the efb to ram and scaled efb restriction
- when upscaling efb copies, mark the new texture as efb copy
- dx12 fixes for the src box, especially the number of layers for 3D
This should get Donkey Kong Country Returns characters to be as broken as they should be. They will be fixed in a later pr.
Expected result is:
efbtex: characters are always flickering or invisible, no matter what scaling or IR setting
efb2ram: characters are always working properly at 1xIR, no matter what scaling or IR setting
This checks every TEXTURE_KILL_THRESHOLD frames, to see if the hash for the memory area of the efb copy has hanged. If it has changed, the efb copy can be removed, it wouldn't be used anymore. Before this pr, some efb copies would never be deleted.
Fixes issue https://bugs.dolphin-emu.org/issues/6101 and possibly some other VRAM leaks.
This fixes issue 6563:
https://code.google.com/p/dolphin-emu/issues/detail?id=6563
This PR adds a 2nd map to texture cache, which uses the hash as key. Cache entries from this new map are used only if the address matches or if the texture was fully hashed. This restriction avoids false positive cache hits. This results in a possible situation where safe texture cache accuracy could be faster than the fast one.
Small textures means up to 1KB for fast texture cache accuracy, 4KB for medium, and all textures for safe accuracy.
Since this adds a small overhead to all texture cache handling, some regression testing would be nice. Games, which use a lot of textures the same time, should be affected the most.
This is the same trick which is used for Metroid's fonts/texts, but for all textures. If 2 different textures at the same address are loaded during the same frame, create a 2nd entry instead of overwriting the existing one. If the entry was overwritten in this case, there wouldn't be any caching, which results in a big performance drop.
The restriction to textures, which are loaded during the same frame, prevents creating lots of textures when textures are used in the regular way. This restriction is new. Overwriting textures, instead of creating new ones is faster, if the old ones are unlikely to be used again.
Since this would break efb copies, don't do it for efb copies.
Castlevania 3 goes from 80 fps to 115 fps for me.
There might be games that need a higher texture cache accuracy with this, but those games should also see a performance boost from this PR.
Some games, which use paletted textures, which are not efb copies, might be faster now. And also not require a higher texture cache accuracy anymore. (similar sitation as PR https://github.com/dolphin-emu/dolphin/pull/1916)
mimimi085181