View Single Post
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#37
Originally Posted by TiagoTiago View Post
The problem there is you made it too simple, lemme try to squiggle out a drawing of what i mean:




Your example there is more of a job for the multiple buttons on each side algo; either way, you forget about the time dimension, at any given moment you always know at least one side for sure because of where the cursor moved to before.
Finished reading thread. Most of the discussion has flown naturally without anything for me to add, however, I REALLY want to point this out, because so few people seem to get it:

The time aspect Tiago mentions is right on. If you have:

A 1 X
B 2 Y
C 3 Z

...then yes, dumb point-of-press analysis will say C+X and A+Z is the same thing. HOWEVER, if your input method is hacked to buffer the last few milliseconds of contact, and checks where the last press was (INCLUDING noting if the last few milliseconds had NO pressure on screen, and having a couple other exceptions which can be logically deduced), then it's pretty easy to tell between person was JUST pressing A, then pressed 2, or person was just pressing A, then also started pressing Z (while not letting go of A); vs person was just pressing C, then pressed 2, or person was just pressing C, then also started pressing X (while not letting go of C).

This STILL has flaws. And unless you have a LOT of spare processor idle time, you probably can't do this well unless you design your own preprocessor hardware that does this (which is how Stantum screens keep the device from having to do all the calculations I alluded to above - they have a chip that does that part, and outputs the specific 'touches (coordinates, pressure, etc)'.

However, this does mean that if someone is willing to sit down and code a robust system like this, at least SOME basic (two joysticks/control pads) methods can be implemented, even if some of the 'center' areas are shared by multiple combinations of individual touches.

A similar concept can easily be used by someone who understands calculus and physics well enough into using accelerometer values for gyroscope emulation.

Much like the above, there's still instances where doing something not-multitouchy/not-gyroscope-y will result in this emulation interpreting it as such. But if you're at all logical about it, and can spare the extra memory, processor load, and tiny amount of (ideally not-human-perceptible) lag, you can figure out how to narrow the amount of such problem instances down to very rare situations.