So, this weekend I went to add some basic code to scrollable-area to make it more touch-friendly, because using 20px-thick scrollbars on an actual phone is a PITA. At least on what I endearingly term "my low-budget crap phone."
Anyway, I ran into a problem: FlxG.swipes reports *any* touch event as a swipe. This isn't a problem in and of itself, as it's useful for custom code. The problem is that, even a distance=0 swipe, which is clearly a tap by anyone's algorithm, shows up in FlxG.swipes. This means we must implement some custom code to distinguish between swipes and taps.
This may not seem terribly complicated at first, but...well, for example, read this wonderful resource to get an idea of the situation.
The next part of the problem, which is a little bit more of a problem, is that basing an algorithm on pixels, rather than a real-world unit of measurement like centimetres, means that the algorithm will work vastly differently on a "retina" device versus an older-generation, lower-density budget device like mine. If I calibrate to retina devices, what would be a 0.75 cm "tap" there could be a 2.25 cm "swipe" on my crap phone...and I wouldn't want a nearly inch-long gesture to necessarily be interpreted as a tap.
So we should know the DPI. Is this possible in HaxeFlixel? Sure, if you want to include custom code for each platform like this library does. A possible workaround, we really just need to start overriding Android Java code, and more or less just exposing the results of this one call, I think.
And if we want something cleaner? Thankfully, there's something in the pipe. Because my game is not far enough along just yet that I'm testing a lot on phones, I will opt to wait. Also because the Java override technique would mean scrollable-area would go from being a fairly straightforward include (even though you have to set up your content offscreen for it, at the moment) to something much more integrated. So, hopefully by the time I'm ready for swipeyness, Lime will be too. :)
No comments:
Post a Comment