Hey all. I was just wondering if the iPhone/iPad port of Allegro handles input tracking. Well, more specifically (of course it handles input; duh), assigning unique IDs to inputs to facilitate multitouch. I know for our last game I had to keep track of unique touch IDs because people wanted to be able to drag two things with two fingers, and the Apple API keeps track of the IDs and sends them with all the input events. I don't see any parameter like that in ALLEGRO_EVENT so I was curious if it was being handled.

It probably wouldn't be cross-platform at all, unless other platforms have a need for that information. We use a void pointer to keep track of each touch and that's all we needed (we weren't originally keeping track of it; I had to add in multitouch functionality afterward). I haven't looked at the Allegro code on this yet, but the iOS tracks touch and assigns unique IDs already so assuming there's room in the union/struct, that should be all there is to it. Unless there's some other consideration I'm not aware of.

Does Allegro 5 support other platforms that have touch interfaces? I honestly didn't think it did.

Well I guess it depends on how they all use it then, since the only one I've used is the iOS version. Can't imagine it's terribly different, but I have no experience.

Anyway, for iOS all you need is the void pointer reference from the low-level API. We just used it as the key in a dictionary of inputs on the high-level side. Worked out fine. How do the other OS's do it?

I can track touches by mouse ups and mouse downs, yes. But are you saying that the mouse.button variable itself is the unique identifier? Because that would actually make sense ...

I'll check that out. What's the maximum number of touches it can track?

iPhone and iPod report up to 5 touches. iPad up to 11 (why?).

Allegro 5.1 track touches. Treat button number as Touch ID (it is indexed from 1 not from zero).
Tested and working like a charm.

Also Window 7 may receive touch support soon. That will probably force us to differentiate between touches and mouse events.

Sounds like a good idea to me! You might have to flip-flop a bit as to which is the "current mouse", but that sounds doable as well.

I agree that mouse and touch need to be separated. They are fundamentally different kinds of input. The only thing they share in common is their ability to indicate X/Y positions on the screen.

Consider a game that supports both mouse and touch input. It is entirely plausible for the semantics to be somewhat different between the two, and the program may want to detect this and offer different functionality. But if touch events transparently look like mouse events, this is not possible.

The simple solution would be to have Allegro by default generate mouse button events for touches. If the programmer wants touch events, then he could explicitly detach the two.

By enabling them, it could also enable touch "gestures" like pinching, etc. It would be nice (although not necessary) if Allegro detected those events on devices that didn't natively support it.

That would be nice if you trying to maximize backward compatibility. Which is not an issue to Allegro ATM.
Multi-touch support is a new (recently popularized) feature. Lack of support for it is not a bug. Cleaner solution is to add yet another input source, events for it. This for the API side.
In the spirit of backward compatibility there may be an entry in allegro.cfg which enable mouse emulation by touch when stated explicitly.

Tablets, trackballs, etc. are pointing devices like a mouse. This is not odd, because the intention was to provide better or more natural control over the pointer.

Multi-touch is quite new philosophy where you have multiple pointers to control. They are not like mouse, because you do not use two or more mice, you're using fingers and you're actually touching device.
Frankly, did someone used two mice in one PC for other purpose than to annoy other user? Touchpad and mouse works, because they are controlled by you and therefore you do not have a conflict.

If someone invent thought-control input, Allegro will (or at least should) adopt to it. Mapping to mouse or keyboard may be a good idea to keep the compatibility for some time, but a new API should be provided to take full advantage of the feature, not only scraps.

So any other touch will be relative to the first one? Simple is better. If touch location will be dependent from other variable (in this case first touch location) this is not real simplification. You then have to remember position of first touch to compute position of remaining. What advantage does it have?

Gesture interpreter do not need help in the form of relative touches. It can very easily calculate them if needed.

The point is to do not hack Allegro to support a feature in some non-intuitive way, but provide and API to do this properly. To keep compatibility a mouse emulation implemented using touches may be provided. May be, because this is very simple task to map touch events into mouse input in application itself. More, if Allegro is a basis for game engine, this is preferred way.

Couldn't agree more to that in general. But here the idea is that a lot of stuff (e.g. most of the A5 examples, but also any button based games) could work fine without any IPhone-specific code if the touch input would emulate a mouse by default. If you want to make IOS specific changes it's easy to simply use the touch events instead (and turn off the mouse emulation, but probably no need for that - just ignore the events).

But I'm also not opposed a lot to separating mouse/touch events. My main reason for wanting this emulations really is just the examples... makes it much easier to test them all on iphone/ipad. If we separate the touch events I'll just add touch event handling to some examples - should only make them a bit longer, but still keep them readable.

The current situation is very bad in any case. We have no emulation (I had put it in but it was broken as it seems to have interfered with actual touch reporting) and no touch events. So worse of both of the above solutions