BUFULO's dashboard

Is it the same song, all songs, & how often does it happen? If it happens every time on a song, post a video! – BUFULO, on October 24, 2009 17:37

Yeah, I know. Apparently it's just not working right now. – BUFULO, on October 24, 2009 17:36

Try doing a Backup & Restore (from that Backup) in iTunes. – BUFULO, on October 24, 2009 17:28

Can't delete posts here now?

The problem is that those "shit" moments you describe are obviously 100% user error. That's a LOT easier to defend than incorrect software "guesses!"

I also still think that if the valid tap time window were truly honored, the complaints wouldn't be nearly as bad as they are with overlap. This is because tappers that are close together in alternating lanes, for example, could be hit out-of-order as long as the tap time window was not violated. Maybe this is a little harder to code, but I truly believe no overlap can be made to work even with the apparent current OS limitations.

Regardless, it would be SO EASY to add an option to reduce the target size. The current "guessing" algorithm could remain in place. Then, when people complain about dropped taps due to overlap, you could just tell them to turn off the overlap (which effectively eliminates the guessing). If that doesn't help, they either need to practice more or take their complaint to Apple!

I just don't believe EVERYONE would prefer overlap. I don't believe Apple OS is that bad at finding the "center" of a touch. Maybe I'm wrong. I do trust your testing, but knowing the variability of play (finger sizes, contact angles, etc.) & given how easy it would be to add the option, I think it's a no-brainer to add the "no overlap" or variable overlap option.

PS. Thanks for the graphic. That's quite the BUTTLOAD of overlap! – BUFULO, on October 23, 2009 21:03

I agree completely that BPP's video proves nothing. Video proof is not easy to get. To really do it right, you need high frame rates & more than one video (multiple angles). You need to capture the actual finger contact with the screen (not easy). It should be easy enough to capture the REALLY obvious drops that occur though - those on much slower songs.

However, I'm also not crazy, am on a few leaderboards, & do know a dropped tap when it happens. It absolutely DOES happen & is mostly random except for the ones due to the overlapping targets issue.

I STRONGLY suspect that most reports of dropped taps are due to the overlapping targets issue & are legitimate complaints even if they don't meet your definition of drops. – BUFULO, on October 23, 2009 19:51

Apple OS does provide just a single point (x, y coordinate) as the location of the touch. However, it is NOT simply the center of the contact patch. The Apple firmware decides (i.e., GUESSES) where you "intended" to touch. Since a "touch" is not a stationary thing (your finger is ALWAYS moving & the contact patch size is ALWAYS changing), Apple has to filter this movement to come up with a single point.

I'm not familiar with touch screen displays (& associated hardware/controller/firmware, etc.). Perhaps the hardware and/or Apple tracks velocity and/or direction to come up with that point. I believe they also take device orientation into account (in real time too?), so they're probably messing with the accelerometers too.

So the bottom line is that Tapulous probably has little control over the definition of a "tap" & felt they needed larger (big enough such that they overlap) tap targets to allow more people to play the more difficult songs.

Regardless, it should be TRIVIAL to allow the user to set the size of the tap targets or, at the very least, have an "overlap ON/OFF" option.

PS. Maybe a future version of iPhone OS will have better support for gaming applications by giving the applications more control over touch events. For example, disabling Apple touch filtering entirely, not tracking movement, etc. – BUFULO, on October 23, 2009 18:40

A "1-pixel" tap zone is a ridiculous exaggeration - even more ridiculous than overlapping tap zones! Hmmm... maybe not. I think I'd actually prefer a 1 pixel tap zone instead of overlap. – BUFULO, on October 22, 2009 19:55

Oops, that example was supposed to read "2 tappers in the left lane, 2 in the center," not 2 in the right. – BUFULO, on October 22, 2009 19:51

It could, & maybe it does, but if the tap areas overlap on side-by-side or alternating tappers, the "guess" could be wrong! Think about it. Two tappers in the left lane, 2 in the right. You tap twice in each lane. If any of the taps in the center lane register in the left, you've lost your streak!

The bottom line is that the software shouldn't assume a tap occurs anywhere other than exactly where it is! What's wrong with that? Just having to ask that question makes me feel like I'm living in some kind of alternate universe or something. WTF? – BUFULO, on October 21, 2009 20:13

What he said! :) – BUFULO, on October 20, 2009 02:31

Another thing... maybe watch that video clip in the "Doubles Issue" thread & ask yourself "why would the software choose incorrectly?" in that case. The answer is because the valid tap time window overlaps AND the valid tap target areas overlap.

Given that Apple probably doesn't provide enough details (latency specifications) or the proper tools to analyze the timing to the degree truly necessary, the only way to fix the issue for once & all is to eliminate overlapping tap time windows & probably overlapping tap targets too.

Each touch event has an associated data structure with a field defining the area touched. It would be the apps responsibility to define a point or anything else it wants to from that information. I think the evidence clearly shows they are not using the center of the touch area. I have no idea exactly what they do use though.

The super simple solution I proposed is guaranteed to work all the time, every single time, regardless of whether or not tap areas or time windows overlap! It's so simple that I suspect there is more to the story (because I don't think the engineers at Tapulous are idiots).

I sincerely hope the only reason for overlapping target areas is to make game play easier! – BUFULO, on October 20, 2009 01:24

Understanding the valid tap time/window is absolutely KEY to this issue! Guarantee you know what it is but you just haven't given the entire issue enough thought.

As I'm sure you're aware, if you tap a little early or a little late yet, it will still register (not miss). Define the valid tap time window as any point in TIME where you can tap without a miss. With a little thought, you'll see that this presents a problem for the case of side-by-side or alternating tappers.

I provided video evidence of the issue in Ceegers thread regarding the "Doubles Issue." At the time, I wasn't even convinced this problem existed & actually thought I captured a simple dropped tap. Ceegers had a keen eye & noticed that the video indeed proved the tap target areas overlap. After that, I examined more video & saw that this was the reason for most of the dropped taps I experienced when my device was otherwise functioning normally (not too long after a Backup & Restore)

Define "tapping dead center!" Anyone with fairly normal size fingers/thumbs can tap "dead center" in a lane & still contact a portion of the evil "overlap" zone!

The key point is that it is IMPOSSIBLE for the software to correctly determine which tap was "correct" when the tap time windows overlap AND tap areas overlap (and you contact the overlap area)! It seems to default "left." Think about it more & you'll understand. – BUFULO, on October 20, 2009 00:49

My camera uses AVI format & I use Roxio VideoWave for basic editing on a PC. Sorry, I don't have a Mac. I thought those came with everything you need to do that sort of thing? – BUFULO, on October 20, 2009 00:28

mashgotcash, re-read what you just wrote - out loud. It's nonsense, especially the first 2 sentences! :) You are also assuming the software can make the "correct" decision when the only truly correct decision is to accept the tap for when & where it is!

Your last sentence is so wrong! What about the case where the valid tap TIME overlaps as well? Overlapping target areas simply will NEVER work properly as long as overlapping valid tap time windows are also allowed!

krohn7master, did the version with non-overlapping targets compare the geometric centers of the tap target to the geometric center of the area passed in the touch event data structure? I bet not. This is would be the best way to do this in my opinion. It would have the additional benefit of being LESS CPU intensive than the current scheme. I do work as a consultant if Tapulous needs some help. – BUFULO, on October 19, 2009 23:04

Define "correctly." How is it correct to tap in one lane & have it register in another? If you can't tap in the lane where the tapper is, that's obviously a dropped tap. Heck, why not have one giant lane?

I suppose it's more "fun" to get higher scores, but I'd rather earn them with accurate timing AND accurate tap position. Overlapping tap targets rewards inaccurate tappers! – BUFULO, on October 19, 2009 22:22

I've done this in the past. You'll probably find that the overlapping tap target issue is causing most of your drops (it is for me) when your device is working well otherwise. There are still times where taps are just outright not recognized (on even the slowest, super easy songs where it's totally obvious).

I'll probably take some more video when I have more time & patience. My stupid digicam only takes 30 seconds at a time at a frame-rate fast enough to see the issue. It also takes a fair amount of time to get the light right (dark room seems best) & transfer/edit the video clips. It's also not as easy playing with a stupid camera in front of you & trying not to move out of the video frame area. Not really worth the time for me anymore since I've done it enough to know what the problems are. – BUFULO, on October 19, 2009 21:57

Worse how? My guess would be the testers got better scores with the zones overlapping. Maybe everyone would be better served by learning to tap more accurately & just accepting that the insanely hard/fast songs are just not going to be possible for everyone to FC or do well at?

Again, this sort of thing should be totally trivial to have as a user-selectable option. It would simply change the numbers when comparing the touch event bounds with the tap zone bounds. Totally trivial & would have zero effect on performance otherwise.

Any chance I could get a version with the non-overlapping tap targets? I doubt it. I suppose someone out there could jailbreak & take a hex editor to the code. Those bounds should just be a constant somewhere in the executable. Might be tricky to find though. – BUFULO, on October 19, 2009 21:50

Until you've tried playing without overlapping tap zones, how will you ever know? Maybe that is exactly the "happy medium" you seek. – BUFULO, on October 19, 2009 21:36

Ahhh... so it's all about you? The rest of us suffer because you can't tap accurately? :) – BUFULO, on October 19, 2009 21:03