Closed ericoporto closed 1 year ago
ivan-mogilko
commented
1 year ago I guess it should be same between touch down and touch up, but may be a different one next time it's down? We may save which finger IDs were down in variable(s) to be able to count number of fingers, and which are moved/upped. EDIT: and do not expect finger IDs to go 0,1,2,3... but be anything.
ericoporto
commented
1 year ago I guess it should be same between touch down and touch up, but may be a different one next time it's down?
Yeah, on my log above they are consistent for a down-motion-up sequence and then next sequence they get a new number.
and do not expect finger IDs to go 0,1,2,3... but be anything.
In this case they appear to be consecutive but I get a feeling they use all the range of the 64-bit id they have. But yeah, I think the idea is to work only with the assumption that each finger ID is unique for all the finger IDs "active" (simultaneous?) - on screen or just leaving the screen.
In the mouse emulation, for the two finger method, can't quite figure the case where one finger is on screen and then a second one is used (for the right click) and then with the second one on screen, the first one is lifted. My guess is we just don't support this, the second finger should only be used for tapping.
https://wiki.libsdl.org/SDL2/SDL_TouchFingerEvent
I noticed that there's also a timestamp member that could be used if needed.
ivan-mogilko
commented
1 year ago Well, following are uses of fingerID:
detect_double_tap() function. Seem to work fine with random ID, as it records them in a variable already.touch.fingers_down and tfinger_to_mouse_but(). First is a bitfield, the second is function. But I put them together as same problem, because both basically convert from fingerID, assuming that it's 0-based and each new finger takes the free ID from the start (i.e. if fingerID 0 is free, then the next finger will be 0).In regards to the p2, the issue here is that in the current logic, the pressed fingers ares kind of "locked" to certain role. As you mentioned above:
In the mouse emulation, for the two finger method, can't quite figure the case where one finger is on screen and then a second one is used (for the right click) and then with the second one on screen, the first one is lifted. My guess is we just don't support this, the second finger should only be used for tapping.
Perhaps the solution may be to remember the finger's role until all of them are released. That is, if you:
And alternate solution is to rely solely on number of fingers. Two examples: ex 1
ex 2
ericoporto
commented
1 year ago
detect_double_tap()function. Seem to work fine with random ID, as it records them in a variable already.
Yes, this is true, the minor note is last_tap_finger can't be an int, it needs to be 64-bit or SDL_FingerID type.
Perhaps the solution may be to remember the finger's role until all of them are released.
This idea of remembering roles looks more correct - it kinda emulates what Android is doing, like first finger down it reserves the 0 ID, and then second finger is down it reserves the 1 ID, if first finger is released and 0 ID is released and then third finger is down 0 ID is again reserved.
This is something that if existed could be reused in a future in AGS touch events, as this would give fingerIDs consistent between platforms. I just wonder if there's something really hard about this, since it sounds like it should be in SDL2 itself, but an alternative reason why it isn't may just be because most of the sdl2 people care primarily for PC gaming.
And alternate solution is to rely solely on number of fingers
This reads like it is easier to implement.
ericoporto
commented
1 year ago Made a fix that works apparently, not sure how good it is: https://github.com/adventuregamestudio/ags/commit/c9b315291dec44ea6e0d60538a4dfa27ea1888b5 (it's the second alternative, that simply uses number of fingers)
Edit: went and attempted the first idea here https://github.com/adventuregamestudio/ags/compare/master...ericoporto:ags:fix-web-ios-touch Edit: made a PR from this.
Can be tested here: https://ericoporto.github.io/agsjs/tst2/
Describe the bug When running our Web port in the iOS Safari browser, clicks are not registered
The reason it appears to be that Touch.identifier works differently in it. The 2013 spec states:
Here is a log after I added three log functions in sys_events.cpp, this is in a simulator, so the mouse is only one finger, I click, move and release I think six times and get this.
AGS Version it happens on current 3.6.0.45, but curiously it did not happen in an old version.
Game https://ericoporto.github.io/agsjs/tst/
To Reproduce Steps to reproduce the behavior:
Expected behavior It's expected to work
Smartphone:
Additional context When SDL own touch emulation was used, there was no reliance in fingerId, so it worked with that.
The API from SDL only states that fingerId is unique, and nothing else, so apparently we can't rely on actual values from it - even though on Android it's consistent with both the App and the Web version on different browsers, it appears on other devices this is not guaranteed.