Implement BizHawk's touch input interpolation changes in the core #2168
Conversation
"Touch input interpolation" here is rather simple: it does a simple linear interpolation against the touch values between the last frame's touch position and the current frame's touch position, using the current frame cycle count. In case the last frame wasn't touching anything, it just touches immediately. The API presented here was originally intended as a way to try to avoid merge conflicts. It is intended that before RunFrame(), the user would call MoveTouch(), then call TouchScreen() once RunFrame() returns. Alternatively, TouchScreen() could be solely called before RunFrame() (this would probably be what the libretro port does, maybe some other ports). This however will run into issues for some games which do not like immediate changes to touch input every frame, rather needing touch input to go slowly across the frame, as touch input gets polled multiple times in a frame (see TASEmulators/BizHawk#3397). melonDS Qt doesn't do this however, instead just calling TouchScreen() within mouse event handlers, i.e. within the UI thread, not the emulator thread. This does end up making it (at least seemingly) avoid issues with games not liking exactly per frame touch changes, but it is just a giant race condition and probably should be changed.
Can you suggest such a problematic game? I'd like to compare the results before integrating this change and after. |
Just see the linked issue, which names such a game and provides SaveRAM for the problematic section. |
"Touch input interpolation" here is rather simple: it does a simple linear interpolation against the touch values between the last frame's touch position and the current frame's touch position, using the current frame cycle count. In case the last frame wasn't touching anything, it just touches immediately.
The API presented here was originally intended as a way to try to avoid merge conflicts. It is intended that before RunFrame(), the user would call MoveTouch(), then call TouchScreen() once RunFrame() returns.
Alternatively, this newer API doesn't have to be used: TouchScreen() could be solely called before RunFrame() (this would probably be what the libretro port does, maybe some other ports). This however will run into issues for some games which do not like immediate changes to touch input every frame, rather needing touch input to go slowly across the frame, as touch input gets polled multiple times in a frame (see TASEmulators/BizHawk#3397).
melonDS Qt doesn't do this however, instead just calling TouchScreen() within mouse event handlers, i.e. within the UI thread, not the emulator thread. This does end up making it (at least seemingly) avoid issues with games not liking exactly per frame touch changes, but it is just a giant race condition and probably should be changed.