The problem is, though, is no one was really aware of these "limitations" (developers or users), at least for the Nexus One. I'll admit I didn't research before buying the N1 that it was "basically the same sensor as the G1"
Up until now, with the addition of multitouch into the SDK, it's been 'Great! We can use multitouch for supported devices' - now it is 'you can use two touches as long as you are careful about what data you accept and hope it works correctly on certain devices'. This affects apps very little (they are probably relying on simple pinch/zoom type gestures, but I could imagine it puts a serious downfall on game developers (I believe that's why you coded the test app, right? Because your users were having problems). My concerns are: a) Google reps saying this 'issue' is directly related to the touchscreen, therefore it's not considered an issue. b) If the problem is because the touchscreen just can't handle crossing/close paths of two points, there needs to be some kind of software workaround to maybe throw out bad points and try to get decent, non glitchy data - so developers can reliably use it. Otherwise, developers will steer away from creating multitouch in games, and you'll lose the edge of competing with iPhone style games (and possibly getting iPhone developers to cross-develop). c) If some devices are capable, and some are not - there needs to be a way to say 'my app requires a device that fully supports multiple touches' - which I'm pretty sure is not possible right now. According to Cyanogen, there is a section in the framework that specifically addresses the software workaround: overlay/frameworks/base/core/res/res/values/config.xml .... + <!-- Enables special filtering code in the framework for raw touch events + from the touch driver. This code exists for one particular device, + and should not be enabled for any others. Hopefully in the future + it will be removed when the lower-level touch driver generates better + data. --> + <bool name="config_filterTouchEvents">false</bool> So this tells me that it is known that either the screen doesn't produce great results, the low-level driver doesn't do a great job, and/or software might need to do some filtering on this data to get decent results. I think I can now see why we had the multitouch confusion, where we couldn't get a straight answer as to why it wasn't implemented. So game developers, can you work around this problem? Or will this cause you to avoid implementing multitouch, since your users will only have problems? My biggest issue is you can avoid using certain 'gestures', but the inverted issues and ghost points will still occur when the user tries to do other gestures - and I'd think you would have to filter those out. -Tim On Mar 4, 12:18 pm, Robert Green <rbgrn....@gmail.com> wrote: > Ugh, these articles are making me out to look like I was on some kind > of expose mission. > > The conversation I had with the guy was like this: > > He said, "Why didn't you use dual analog joysticks?" > I said, "Because it won't work right on HTC phones. Run my test app > to see why." > And now there are 200+ articles about it... > > Hekki - This is not a bug. It's just a limitation of the specific > touch screen on HTC phones. Multitouch works but the point of my app > is to show game developers what does and doesn't work on specific > phones so that they can plan their control systems around that instead > of developing a control system that doesn't work (like I did on my > first try). > > On Mar 4, 4:49 am, Hekki <kaye...@gmail.com> wrote: > > > Ah maybe we're going to be allowed to file a bug report now that the > > all word knows with clue : > > >http://www.mobilecrunch.com/2010/03/03/nexus-one-multi-touch-bugs > > > Please tell us you are working on a solution or that there is no > > solution and we should not rely on multitouch for our apps. > > Either way, but don't let us in the dark please. > > > Diane, Romain, Fadden, anyone give us a clue please. > > > Yahel > > > On 3 mar, 17:48, Peter Kirn <peterk...@gmail.com> wrote: > > > > Dianne, I'm unclear about just one thing here -- which "special code" > > > -- you mean the code in the sample apps? > > > > Relative to the conversation since -- I don't disagree; this isn't an > > > Android "bug" and it theoretically should be in the device driver. It > > > does raise a question, though, about the API design. If handset makers > > > are delivering data that doesn't work the way developers expect, and > > > the hardware itself can't be "fixed" (which it most definitely can't), > > > then the question is, how do you bridge the gap between what the API > > > appears to provide and what's actually there? > > > > On the other sensors, we have the ability to set sensitivity and make > > > appropriate resource consumption tradeoffs, as with the timing > > > resolution of the accelerometer, for instance. Why not provide > > > something in the API that allows corrected data - with the tradeoff in > > > interpolation -- in case raw data is not accurate enough? For that > > > matter, given the wild variability here, maybe there needs to be some > > > sort of additional information provided about the device beyond just > > > whether it provides for these second+ touch points. > > > > Peter > > > > On Feb 12, 2:42 pm, Dianne Hackborn <hack...@android.com> wrote: > > > > > Sorry I meant exactly what I said: this is how the touch screen > > > > hardware on > > > > the Nexus One works (which is essentially the same screen as on the G1 > > > > and > > > > myTouch). The Droid has a sensor from a different manufacturer, with > > > > different behavior. Other phones will likewise have different sensors. > > > > > This has nothing to do with the Android platform. Please do not file > > > > bugs > > > > about it. Android is just reporting what the hardware is capable of > > > > reporting. There is no "normalization" for games or such, there is > > > > just the > > > > data the screen provides. (Though there is some special code in the > > > > current > > > > framework for cleaning up the data from the Droid screen; arguably this > > > > should be in the driver or firmware for it, since this is really screen > > > > and > > > > hardware specific kind of stuff. At any rate, it is not applicable to > > > > basic > > > > screen capabilities like here.) > > > > > There is a good analysis of the G1 class touch screen here: > > > > >http://lukehutch.wordpress.com/2009/01/10/full-working-multitouch-on-... > > > > > On Fri, Feb 12, 2010 at 4:39 AM, Sean Hodges > > > > <seanhodge...@googlemail.com>wrote: > > > > > > I think what Dianne is saying is that the values you are seeing are > > > > > what is raw data returned from the sensor, it's not normalised for > > > > > multi-touch games, or for any particular purpose. > > > > > > My understanding is that the values returned have different coordinate > > > > > spaces, and have a tendency to "jump" about when used directly (I > > > > > suspect this second issue is more an artefact of the device-specific > > > > > screen sensitivity, dents, scratches and the impact of screen > > > > > protectors). > > > > > > Take a look at Luke Hutchison's multi-touch controller, it might > > > > > provide a suitable wrapper for your requirements: > > > > > >http://lukehutch.wordpress.com/2010/01/06/my-multi-touch-code-ported-... > > > > > > On Fri, Feb 12, 2010 at 8:39 AM, Kevin Duffey <andjar...@gmail.com> > > > > > wrote: > > > > > > Ugh..sorry.. I hate using my moto droid to reply.. fat fingers and a > > > > > > horrible physical keyboard don't go together. > > > > > > Dianne, I don't understand your response.. it's quite clear from > > > > > > several > > > > > > developers that the multi-touch has problems severe enough that > > > > > > it's deterring game developers and others that would use it. You're > > > > > saying > > > > > > that it's normal behavior for the multi-touch to change the > > > > > > location of 2 > > > > > > touches such that one of them is completely not in the location of > > > > > > where > > > > > you > > > > > > touched it? Is this an Android platform issue with how it handles > > > > > > sensor > > > > > > data.. or are you saying that the G1, myTouch, Nexus One and Moto > > > > > > Droid > > > > > (not > > > > > > sure about others) ALL have built their touch sensors to purposely > > > > > > report > > > > > > this sort of behavior when you touch, then release, then touch > > > > > > again as > > > > > > Robert and several other posters have state is happening? > > > > > > > On Thu, Feb 11, 2010 at 7:46 PM, Dianne Hackborn > > > > > > <hack...@android.com> > > > > > > wrote: > > > > > > >> On Thu, Feb 11, 2010 at 6:10 PM, Kevin Duffey <andjar...@gmail.com> > > > > > wrote: > > > > > > >>> So what I want to know is what is being done about this? Is > > > > > >>> there a > > > > > bug > > > > > >>> file and if so is it > > > > > > >> This is how the sensor hardware works. It is essentially the same > > > > > sensor > > > > > >> as the G1 and myTouch. Please don't file a bug about it. > > > > > >> -- > > > > > >> Dianne Hackborn > > > > > >> Android framework engineer > > > > > >> hack...@android.com > > > > > > >> Note: please don't send private questions to me, as I don't have > > > > > >> time to > > > > > >> provide private support, and so won't reply to such e-mails. All > > > > > >> such > > > > > >> questions should be posted on public forums, where I and others > > > > > >> can see > > > > > and > > > > > >> answer them. > > > > > > >> -- > > > > > >> You received this message because you are subscribed to the Google > > > > > >> Groups "Android Developers" group. > > > > > >> To post to this group, send email to > > > > > android-developers@googlegroups.com > > > > > >> To unsubscribe from this group, send email to > > > > > >> android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > > > > >> cr...@googlegroups.com> > > > > > >> For more options, visit this group at > > > > > >>http://groups.google.com/group/android-developers?hl=en > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "Android Developers" group. > > > > > > To post to this group, send email to > > > > > > android-developers@googlegroups.com > > > > > > To unsubscribe from this group, send email to > > > > > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > > > > > cr...@googlegroups.com> > > > > > > For more options, visit this group at > > > > > >http://groups.google.com/group/android-developers?hl=en > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "Android Developers" group. > > > > > To post to this group, send email to > > > > > android-developers@googlegroups.com > > > > > To unsubscribe from this group, send email to > > > > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > > > > cr...@googlegroups.com> > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/android-developers?hl=en > > > > > -- > > > > Dianne Hackborn > > > > Android framework engineer > > > > hack...@android.com > > > > > Note: please don't send private questions to me, as I don't have time to > > > > provide private support, and so won't reply to such e-mails. All such > > > > questions should be posted on public forums, where I and others can see > > > > and > > > > answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
