Slow response from touch event - ie more like "press for half a second" rather than "touch"

furtiveimagination

Hi, I have finished and published my first full project from scratch and am pretty pleased with it, apart from one problem I was hoping would not be too noticeable in the final release as I don't seem to see any solution for it.
However, the more I use/test my new app, the more I am bugged by this, and am worried it will cause uninstalls soon after download from the play store!
The problem is a slight delay after touch before the actual touch event is registered and actioned - I have several buttons on the screen, all around 80 x 65, that you should be able to just lightly and quickly touch and move to the next button, but what actually happens in the app is the button is touched but nothing happens for a fraction of a second, then the touch is registered and actioned as it should!
It is this fraction of a second delay, meaning you have to touch and hold the button rather than just touch it and move to the next, that is ruining the whole feel of my App.
Everything else works fine otherwise, can anyone let me know if this can be fixed so that touches are registered and actioned instantly so you don't need to hold the button until it registers?
If you want to check out what I mean for yourself the App (CC100) is in the Play Store here and free to download.
I hope there is a solution and that you guys have the answer,
Thanks.

furtiveimagination

Hi Guys, thanks for all your input, I have an update - I have discovered the source of the problem and thought I'd post my findings here for reference should anyone else find themselves in the same situation as I was.

The fact that the problem that I had seemed to be a rare one, judging from the comments in this thread and the fact that I couldn't find it anywhere else on the forum (hence my having to start a new discussion for it) suggested the problem was something I was doing differently to anyone else here.

So I decided to go ahead and optimize to the max, which took time and study since I'm new to Gamesalad, but did improve things a bit, but not enough to have "solved" the problem.

So I was at the point of giving up and moving on rather than waste any more time on it, when I accidentally discovered what was causing the problem - in a setting on both my devices!!!

Specifically, the Accessibility setting "Magnification Gestures", which I set on both tablet and phone to be able to zoom in on details to inspect more closely while testing using a triple tap on the screen - which can be very handy.

Well unfortunately this is what was slowing the touch response time down - even when not in use! Since when I turned the function off, the touch response from my Gamesalad created App was now virtually instant, just like I thought it should be and you were all stumped as to why it wasn't (and to be fair - how would you know it was down to an obscure Android setting interfering with touch like this!).

Now I had never noticed this "touch slowing effect" with any other App on either device, only with Gamesalad created Apps for some weird reason and so completely overlooked it as a possible cause, and since I was testing it on two otherwise different devices I thought I was eliminating a device specific problem.

So for anyone reading this with similar problems, or that want to avoid similar problems, the moral is - test on as many devices as possible, including devices owned by someone else if possible, or at least on several "factory standard" set up devices if possible.

Anyway, thanks for the input again, problem solved, onward and upward and lesson learned, hope it helps someone else one day :-)

Chunkypixels

It sounds like its something that should be fixable. You'll probably need to post a screenshot of your logic/code for the button press so that people can see what the issue is, and give you pointers to help resolve it.

A screenshot of the relevant bit of logic is usually the clearest way for people to be able to scan through and see whats wrong, short of putting up an example project file/template.

furtiveimagination

Ok, I'll try to get a screenshot up here then, and thank you for the rapid response!!

furtiveimagination

Here is a screenshot of one of the number buttons in the "input number" module of the App.
I have the button actor and four copies in a column, each copy has its own self.image which is used to decide what happens when the button is touched.

One thing I did wonder is, I have put the code that deals with each copy button one after the other instead of nesting them in one big if/else nested decision block, because the PC creator slows down to an unuseable pace, almost grinding to a halt, if having to deal with if/else nests of more than a couple of levels, but has no noticeable change in pace if the decisions are all in series.

Which makes little difference to the way the code runs except it will have to go through all the alternatives even if the first case was valid, which it wouldn't if they were nested of course - as then the "esles" would be skipped altogether.

I didn't think the few decisions I would have here (only five buttons/decision blocks in each column) would have much of a noticeable impact on running speed, or was I wrong and this is where my half a second or so delay is coming from?

It is only less than half a second delay, but enough for you to have to consciously hold the button for a split second and wait for it to respond - which becomes annoying after a while as you can imagine.

The_Gamesalad_Guru

@furtiveimagination said:
Here is a screenshot of one of the number buttons in the "input number" module of the App.
I have the button actor and four copies in a column, each copy has its own self.image which is used to decide what happens when the button is touched.

One thing I did wonder is, I have put the code that deals with each copy button one after the other instead of nesting them in one big if/else nested decision block, because the PC creator slows down to an unuseable pace, almost grinding to a halt, if having to deal with if/else nests of more than a couple of levels, but has no noticeable change in pace if the decisions are all in series.

Which makes little difference to the way the code runs except it will have to go through all the alternatives even if the first case was valid, which it wouldn't if they were nested of course - as then the "esles" would be skipped altogether.

I didn't think the few decisions I would have here (only five buttons/decision blocks in each column) would have much of a noticeable impact on running speed, or was I wrong and this is where my half a second or so delay is coming from?

It is only less than half a second delay, but enough for you to have to consciously hold the button for a split second and wait for it to respond - which becomes annoying after a while as you can imagine.

A touch is pressed is a momentary action so the code will only fire for as long as you have it pressed. change it to touch is released. released works more like turning a switch on and leaving it on. Pressed works like a button you need to hold down to keep the light on

furtiveimagination

Hi Sorry about the delay replying - had to be away from the computer for the weekend.

Thanks Lost_Oasis_Games though,
I never thought of that, it seems counter intuitive as you would think the quickest way would be to react as soon as a touch is detected.

Also, everything is working perfectly fine functionally, so it's not that the result of the touch is wrong, it's just the speed it detects and reacts to it that is wrong, and I will probably have to re-jig everything else that relies on the touch event since it is all geared around the "is pressed" rather than "is released" so it may take a while for me to go through and get everything working that way instead, but I really do need to sort the response time of these touch events as I think it may be a deal breaker and if you're right (and you probably are of course) it'll be well worth the effort!

So I will try your suggestion nevertheless and let you know how I get on.

Thanks again.

furtiveimagination

Hi, I decided to try a quick test with one button and one display to test if I'm maybe just using too many buttons or if it is the "touch" or "release" thing.

Interestingly, there didn't seem to be any difference - the delay was still there even with only one button and one display, and was the same with either touch method, except with the "is touched" method you saw the reaction and then knew to lift your finger, whereas with the "is released" method it was hit and miss as you have to guess how long to hold the button before releasing, so it actually "felt" slower/more frustrating with the "is released" method anyway!

Of course this test was in the viewer, which will be slower than a live build obviously, but otherwise, Should there have been a difference and am I missing something or is there an inherent split second delay with the touch response in Gamesalad anyway?

Thanks for the advice.

DigiChain

I've always used Touch Pressed rather than Touch Released and never experienced a problem or delay - so this can't be your issue.

furtiveimagination

Hmmm! Thanks DigiChain,
If you've managed to do it with no delay I don't suppose you have something I can download as an example with several/many touchable buttons on screen at once so I can see how Gamesalad can handle many touchable buttons when done properly? (either in project form (PC preferably) or APK form with description of your method maybe?)

Hopscotch

@furtiveimagination said:
I have several buttons on the screen, all around 80 x 65, that you should be able to just lightly and quickly touch and move to the next button, but what actually happens in the app is the button is touched but nothing happens for a fraction of a second, then the touch is registered and actioned as it should!

Is 80x65 the dimensions or is that 5200 buttons with rules?

If this is so, then you definitely will need to change your logic. No tool will perform well with that kind of load.

Consider not using individual buttons, but a background image. Then calculate the touch position on the scene, possibly spawning an animated frame over the pressed button location to indicate a press. Then your code will be responsive.

furtiveimagination

Hi Hopscotch, WOW! could you even fit 5200 buttons on screen? Haha! no the buttons are around 80 x 65 pixels big each - there are only about 15 to 20 buttons on screen at one time but about 3 sets of these which are swapped in/out depending on the App "Mode", so only one set of 15 to 20 buttons at a time actually visible on screen.
I might try the background image with spawned animation effect though,
thanks.

Hopscotch

@furtiveimagination , I am relieved

Yet, 60 buttons should not give the delay you are talking about. How many rules do each contain? Is your app otherwise unresponsive?

Give the relative normal number of actors I would look at the current code for things which interfere with each other before re-coding the touch.

Socks

@furtiveimagination said:
I might try the background image with spawned animation effect though,

Hopscotch's background image suggestion was based on the (frightening!) idea that you had thousand of buttons, now that you've explained that you've not got 5,200 buttons (still screaming ) there's really no need use the background image suggestion.

'When touch is pressed' works and will give you an instant response, if it's not instant then there is an issue with your code need to track down and fix.

furtiveimagination

Hmm! ok, thanks guys, I didn't think 60 odd buttons, with only 20 on screen, should cause that much delay, and I think there are a few things that I've already spotted that might be duplicating already completed tasks so maybe its just a matter of re-arranging my logic.
One possible reason I'm suspecting, as I mentioned in my original post, the PC creator grinds to a halt (freezing - unable to scroll through the logic to edit it) if there are more than a couple of layers of "if/else" rules in one block (if this condition do that thing else if another condition do another thing else if a third condition do a third thing etc) so I have to repeat certain condition tests instead of nesting them, another layer in, on an existing rule, and put the new tests directly after the one before, in its own "Rule", which doesn't slow the scroll speed at all, but means I have to repeat some of the if tests.

furtiveimagination

Hi guys, I have tried optimising my logic and there is still a delay between touch and action.

So I decided to try generating, signing and side-loading onto my HTC One M9, a simple test signed APK with one button and one display - no graphics and no logic to speak of to slow things down, just one simple rule in the button actor to increase a global/game text attribute called "count" and one simple rule in the display actor to display that attribute.

I am still getting a half second delay between touch and action - I touch the button and have time to swap my gaze from the button to the display and actually see the slight pause before the display changes! surely this can't be right? how could you control a player actor that needs split second timed jumps etc when there is an unavoidable half second (at absolute best - without ANY game logic whatsoever) delay between touching the screen and the actor jumping?

So I must be missing something right? But what could I be doing wrong when all I have are one actor and one display with one simple rule for each and one global/game attribute?

I even tried UN-checking "Fire TV Remote Supported" and changing the "Aspect Ratio Adjustment" to "Letterbox" on the publishing page - still a half second delay, I changed the text attribute to an integer one - still getting the delay! And no the button isn't too small, I used the default size for an actor - 120 x 120!

There is no delay at all in the native preview in the creator though (when I hit the "Play" button at the top of the stage section of Creator), just in the viewer on my phone and any APK I build and send to my phone. And no, it's not my phone - the same happens on my Tablet (Nexus 9)!

Is there some general or publishing setting in the GameSalad Creator I'm missing that is slowing the response time down in the generated APK?

There has GOT to be a way of getting a near instant response from a simple touch event like this in GameSalad!???

The_Gamesalad_Guru

I'm not sure what you got going but I have never seen this issue. Nor have I heard anyone else express it as this would be major. Not sure what is going on.

Hopscotch

Interesting finding @furtiveimagination and thank you for sharing the info.

I would suggest opening a bug report detailing the settings on android, a simple sample project showing the issue, and clear instructions on how to reproduce.

furtiveimagination

Ok will do.