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.



Regarding the accuracy of the thumbstick while combined with buttons, i don't know how to program well enough to actually code a proof of concept to test the limitations, very preliminary tests using the accuracy thingy in Healthcheck seems promising, some sort of filtering will probably be needed, but it looks like it's worth further investigations.

Sorry, I was trying to make a point to gerbich, who made a claim that he could emulate all multitouch gestures with his touch and swipe.

I prefere this one:
http://www.youtube.com/watch?v=66RBfrBgL2E

Your Video is on a iPad. On an iPhone with the same size of the n900 you couldn't even draw 1 line.

The user of the iPad needs special wearing and and special stylus.
He can't draw details because the screen is not pressure sensitive.

What he does is very dangerous. If the pinch gesture is not correctly recognized he will have a false line instead of a pinch gesture. I preferre the buttons on my n900 that are less dangerous for such an exercise.

In this case a mode change would be very useful. But the iPad has not enough buttons.

It's better to paint on the little n900 than on the big iPad. Because the screen and the buttons are better for such a work.

But for panning and zooming there is no mode change needed. Panning is done by the swipe gesture. Zooming and Rotationg are done by tap&swipe.

If you want to work without buttons like the user on the iPad I propose a standard tap&hold for mode change: Between drawing and moving.

The n900 is much better for painting than the iPad that is much bigger because the concept of the n900 is more intelligent.

@gerdich, I think you've successfully trolled yourself. Just reread the replies above and come to your own conclusions.

If that didn't help, perhaps you'll need to wait to own a multitouch device yoruself to understand.

Hi,

I think software emulation of dualtouch is possible (dualtouch will be very useful for example in palm pre games).


Videos about resistive screen emulation

http://www.youtube.com/watch?v=ld_kIpLWa3Y
http://www.youtube.com/watch?v=XndW7YlvYjU

Maybe this will be helpful http://lii-enac.fr/en/architecture/l...ndex.html#xorg

I think easiest way (to emulate multitouch in palm pre games) is write software to emulate points on screen from input keybord, for example coordinate point (100, 100) will be "A" key, coordinate point (200,300) will be "B" key etc. This software should have configurable coordinate points assigned to input key's.

Sorry for my bad Englisch

Okay, for once I'm skipping most of the thread before saying anything, I just wanted to reply to the initial point early on about Stantum screens specifically:

The way stantum screens are able to pin-point a touch location with more precision than they have sensors for is simple math (well, calculus, if you understand where the basic math transits over into calculus, but whatever) - you detect "this cell is reporting contacts on [set of points], with (amount) of pressure; this cell is reporting contacts on [other set of points] with (other amount) of pressure". And so on for every "cell". Even with only four different cells (assuming they're arranged as squares) you can calculate where in between those cells the touch is.

And I'm not 100% sure the response javispedro gave me is accurate, but it makes sense. The layman's explanation on the Stantum site shows that the two 'layers' of the screen have a bunch of tiny transparent 'separator' dots. Logically, I can understand how this can compare to having a 'bunch' of mini-screens. I can see how this prevents the normal all-touches-register-as-one-big-touch problem. Imagine a giant cellophane layer stretched over a rectangle. If you press it down, it bulges in. If you press it down in two places, simple physics makes it the two inward bulges blend together into one elongated bulge (though this also suggests that with proper mathmatic calculations, you may be able to distinguish single 'point/circle touch' from 'blob/odd-shape touch', if those calculations don't force too much resource use constantly.

Anyway, if you stick a bar along the middle of the empty space over which the cellophane is stretched, the bulge from a press across one 'section' can't reach across the other. So you can now detect two touches so long as they are in separate sections, AND, if you press down both sections at once with something really really big, you can calculate the center of the really big touch by using the positions/pressure of touches detected in both sections.

Now expand the concept to practically microscopic 'sections', and you have an infinitely-expandable multitouch screen. (Unlike modern capacitive screens, which have to be built in a way that lets them distinguish a certain amount of current changes, as I understand it.)

And, I just had another revelation while typing this: When you scale these 'sections' to the point where they're small enough to be barely distinguishable visibly, something else happens - you can make the distance between the two screen layers smaller, and the actual screen material more flexible: Because doing that on a normal resistive screen would make it possible for the screen to just 'sag' on itself under it's own weight, or would make it too imprecise - however, having these microsections means that you can afford a more 'flexible' screen material, and a smaller gap between the two screens. Which means that suddenly, creating resistive multitouch technology simultaneously allows you to increase the sensitivity of the screen as a side effect. Which more than explains, in my mind, how Stantum can claim that their screens can both process infinite touches (they can process however many touches as they have cells on the screen, and that's in the thousands on a modern screen, which is more than you'll ever realistically be able touch the screen with simultaneously), and how they can claim great sensitivity - making the resistive screen support multitouch also makes it practical to significantly increase sensitivity.

...Actually, the whole thing's kinda genius. Like, I'm really sitting here going "holy **** that's brilliant".

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.

Probably this can be interesting for you

http://www.fcl.fujitsu.com/en/releas...0101109-3.html

I am going to be infinitely pissed if this gains traction, but Stantum's long-existing ones don't.

Indeed. Since there's nothing specific other than it being a "software based solution" I'd say they're trying to sell fake multitouch.