This is something I’ve noticed occasionally since a few years ago; sometimes a tap won’t be detected.
This doesn’t happen on my typical test devices very often, but sometimes reviews from Google Play mention that taps aren’t always detected, and now I have a test device where the problem is very obvious (Motorola Moto E5 Play).
On this device, if I tap quickly the tap is usually not detected; I have to hold my finger longer for it to register. At first I assumed this was due to a lower framerate, but even with 60 fps the problem remains. When navigating in the Android system, taps are detected without issues.
I am using HaxeFlixel, so there’s a possibility that the issue comes from there (although it seems unlikely), but before doing more tests I’d like to know if this is a known issue with OpenFL? Thanks.
We used to have a sleep built into the SDLActivity (that we added) in order to improve performance because of overactive touch events on some older Android devices:
Perhaps it would be possible to try this with a current version and see if it helps? We may be able to apply this patch locally again
It didn’t work as-is, but I tried increasing the sleep time on recent Android versions (since this device has Oreo 8.1.0), and it worked great with a delay of about 80, like so:
Thread.sleep((Build.VERSION.SDK_INT < Build.VERSION_CODES.FROYO) ? 16 : 80);
What is the disadvantage of having this high delay?
That would make input run at about 12 FPS. I wonder if the issue is really with the input events not firing (like on
lime.ui.Touch) or if it’s not rendering/registering/behaving as expected within Flixel or your app for another reason
Indeed, it seems that the problem comes from Flixel. If a touch starts and ends during a frame, from Flixel’s point of view in the next frame it’s as if the touch never started, since it overwrites the state of the touch from “just pressed” to “released”. But the touches themselves are all detected.