Is there a way to access the timestamp of a touch event?

[FHBlah]

Hi folks, I'm converting an old suite of Cocos2d apps to Axmol. These are timing apps that need to know the time at which touch events occur. When I tried to do this in the onTouchBegan method, I couldn't find any timestamp data in either the Touch or Event parameters. In old Cocos2d Objective-C, it was available in the Event parameter; event.timestamp. Am I missing something? Thanks.

[rh101]

Given that Axmol is based on Cocso2d-x. if the field did not exist in Cocos2d-x, then it is unlikely to be in Axmol either. You would have to check the differences between Cocos2d and Cocos2d-x to figure out why it was removed.

Would it not be sufficient to get the current time stamp in onTouchBegan using the standard library?

[FHBlah]

Hi RH. I have no idea how much time can pass between the touch and the touch event. However, processors do keep getting faster. I suppose just taking the current time in the onTouchBegan method might be quick enough to avoid noticeable delays. I'll have to try it and see. Thanks bud.

[rh101]

I was curious about this, so I checked the Cocos2d-ObjC source code (from here), and I couldn't find any reference to a timestamp value in the touch event. Did you by any chance modify the engine code to add this functionality for your own projects?

Regardless of that, if timing like that is critical, then it may be beneficial to test the delay between the touch being received by the platform specific handler, and when the onTouchBegin() is called. A few AXLOGD calls in the right places would suffice.

[FHBlah]

Did you by any chance modify the engine code to add this functionality for your own projects?

Nope. In fact, at the time I expected the event object to have a timestamp and when I looked it up, there it was. This was over ten years ago in an early version of cocos2d. I'd look up which verison but the projects are so old my xCode (26.0.1) crashes when attempting to open them. That's why I'm rewriting them in Axmol. Also, Apple is threatening to take them off the App Store if I don't update them before the end of the month.

...it may be beneficial to test the delay between the touch being received by the platform specific handler, and when the onTouchBegin() is called. A few AXLOGD calls in the right places would suffice.

I was also curious about this so I traced the touch events back to RenderHostView-ios.mm's touchesBegan and touchesEnded methods to put in some logging calls. Once there, I found that the platform's Touch object did in fact have a timestamp so I changed my mind and decided to modify the engine code as you suggested. I'm not an engine guy so this was scary for me. Nevertheless, I was able to bubble the timestamps up to my app without blowing up Axmol. Turns out the delay ranges roughly from 0.010 to 0.017 seconds.

These apps are designed, among other things, to help people improve their timing. 0.017 seconds may not seem like much but we (mushy carbon based life forms) are capable of this level of accuracy. For example, if you foolishly write a metronome app that relies on the scheduler to play a tick sound at regular intervals, you'll get a noticeably (and laughably) inaccurate beat. The visual equivalent is having a series of equally spaced dots on your screen. If you move one of those dots over by a few pixels, your eye can easily detect the flaw. My metronome uses an audio queue to generate tick sounds. With a consistent bitrate of 44000 bps, it's much more precise and reliable. I'm hoping that, by subtracting the varying event delays from the touch times, I can better determine how close the human's touches are to the metronome's tick sounds and, as a result, more confidently inform them of how bad their rhythm is.

As always RH, thank you for your time and suggestions. What would I do without the Axmol gang? You people are the best!

[rh101]

Now it makes a lot of sense why you require such precise timing. The 0.10 to 0.17 indicates that it is tied to the update loop frequency, so for a 60 FPS setting for the app (or device), it is 1/60 = 0.16667. The range you're seeing may be as a result of when the system registered the touch, and when it broadcast as an event by Axmol, either in the current or next update loop. Even if this were to be used, if there is any lag and it suddenly drops to 1/30 FPS etc., the difference would be even worse.

I'm not sure if your use case is unique, so if you feel that this should be something that would make sense adding to the engine, then consider submitting a feature request. Implementing it would also depend on whether such timestamps are possible on platforms other than iOS.

[FHBlah]

The update loop frequency, of course. There it is.

As for my use case, these apps are for iOS only. I did plan to circle back eventually and replace them with more gamified (fun) versions. The fact that the timestamps were deliberately removed from Cocos2d-x (and late Cocos2d) implies they weren't available in some way. Maybe they were looking into cross-platform at the time. I haven't worked with Android yet so I'm not equipped to look into it. At any rate, I've got a workaround.

Good health and all the best in this new year.