When testing a recent WIP, I discovered that the iOS simulators running the interpreter (iPad Pro, iPhone X and others) were ignoring my raw touch events around 50% of the time. The standard GetPointerState() and GetPointerX/Y() functions worked fine, but I was using multitouch/raw touch for most operations.
Further analysis reviewed that on some launches/broadcasts of the app, the GetRawFirstTouchEvent(1) and GetRawNextTouchEvent() commands would always return long negative indexes instead of positive ones, such as -1126844592.
All of my touch handling was designed in the same fashion as the included demos and code snippets, and how I imagine almost everyone here does it:
touchID = GetRawFirstTouchEvent(1)
while touchID > 0
// ... Handle touch ...
touchID = GetRawNextTouchEvent()
endwhile
Since the while loop is checking if touchID is
greater than zero, any time the app would run on a device where the touch IDs were negative none of that code would be executed.
The solution - simply change it to:
while touchID <> 0 Now when no touches are down GetRawFirstTouchEvent(1) will be zero, but in all other instances it will represent an index that can be any non-zero integer. The code still functions correctly once this change is applied.
Looking into the cTouch.h header of the AppGameKit include, I see that m_iUniqueID is of type
UINT (unsigned integer). So technically negatives should never be occurring but however AppGameKit is retrieving/converting the touch reference in such instances seems to be overflowing it or otherwise causing it to be signed negatively. I am not sure whether or not this occurs on actual devices but given even the chance that it does (and if you ever wish to test on simulators while using raw touch) I recommend updating to check against negative and positive indexes.
