Closed DonLoquacious closed 8 years ago
This all looks good with one exception: requiring touchesEnded before firing the event wont work for most games. Any fast-paced game needs to have the event firing as soon as criteria is reached so action can be taken.
Good point. In my specific use-case, I'm having to be a bit more conservative with swipe recognition, since I'm also using custom shape recognition like circles and stars, and this would fire prematurely. If custom shape recognition isn't common enough for this to be the standard, then perhaps a boolean option for choosing between "fire on first recognized" or "fire when touch is released" may be better? Or would this be over-complicating the core functionality, and such an option should be left for people to make for their specific implementation?
The old version would detect swipes the moment the criteria for a "swipe" was met- this means checking for that criteria every single frame and firing the event mid-swipe before the finger is released, it would only detect swipes in the four cardinal directions, and it stored and checked no information about the intermediary points within the motion- only the first and final touch positions.
In this updated version, the criteria for a successful swipe are checked and (if successful) the event fired only in the frame that the touch ends (when the finger is picked up from the screen). In addition, four more directions have been added to the possible swipe recognition list for the four diagonal directions, an additional check is performed for "line straightness" which takes the total cumulative point-to-point distances for all sampled positions during the swipe motion and compares it to the "ideal distance" from the starting to ending points- failing if the cumulative total is more than 10% greater than the ideal (motion not straight enough). This keeps fast "V" motions on the screen from registering as directional swipes.