Nevermind... the plugin doesn't work for mobile platforms yet...

[quote:32ixl9r1]Compatibility

Unfortunately at this time Google Play Game Services only work from a web browser. It does not currently work from Crosswalk or any non-browser wrappers like CocoonJS or Ejecta. However it should still work on mobile browsers such as Chrome for Android. ~ https://www.scirra.com/manual/175/google-play

In the Google developer console it says "Google Play game services let you add social gaming features to your games on Android, iOS and the web."

So I am assuming it works on windows phone and blackberry? Has anybody tried?

Colludium Yeah, I tried that before implementing the 4 sprite system. I found that it caused some other unexpected issues. Basically I rotate to a specific angle depending on the edge that the collision occurred on. With 'Is overlapping at offset' it made my sprite spin. Which makes logical sense. This didn't happen with using 4 sprites. I would have to debug to find out more and is probably just a matter of tweaking. For now I have disabled those events and will come back to it when I need to optimise as right now I am prototyping.

xach I agree, but I'll wait until it actually causes problems before I refine it

Is there anyway to see collision checks in the debugger?

Cheers guys. So I have tested all the above. I found with my situation the most reliable method was to create four simple sprites. Offset them from the player sprite position so you have one above, below, left and right. Then for each of the four sprites use the action 'is overlapping another object' with 'trigger once' Then set them to invisible.

Although I know this isn't the most efficient method it gave me perfect results when testing the player sprite moving at a high speed. With the others I found they would sometimes flag the wrong side. I suspect this is because when moving at the speeds I need the collision can be flagged when it is quite far into the object.

Thanks again for your help.

Hey guys,

Lets say I have 64x64 sprite that I call player. Then I put it in a level made out sprite tiles and I make the player move randomly around in it.

So I want to know which side of the player has hit a tile i.e. top, left, right and bottom.

Any ideas? (please give a short example based on the above)

Kind regards,

Wyrm

Ok, thanks for the info. I have scaling working as I want so far just need to test it out on a bunch of tiles. I will let you know what i choose. Thanks again.

ah ok, that explains it! I assumed it was the same as the math order!

Good spot! Thanks again!

Thanks you're a star. So essentially you used absolute position of the touch on start and again at touch end. Where absolute refers to the current position of a touch over the canvas area. So I may use this as it side steps the problem.

HOWEVER, I am still interested in why my original doesn't work to further my knowledge. Anybody have any ideas?

and a general observation that i noticed is the further right the sprite is in the scene the greater the resulting distance.

A few more details.

-Dragging from the sprite to top left produces small distances than dragging to the top.

-Sometimes the sprite can get stuck. Just refresh and try again.

Hi guys,

I expect the player to be able to touch a sprite, drag and release to determine the direction and force to launch the sprite. So the further away I drag the greater the force in the direction of the touch end.

However, I find that the force seems to be inconsistent to if I drag left and release compared to when I drag right and release.

I have attached the capx so you friendly people can help my find out what I've missed.

My thoughts at the moment at potential problems are maybe different co-ordinate systems or taking touch co-ordinates incorrectly or at the wrong time? Thoughts?

Kind regards,

Wyrm

Thanks, I'll give it a whirl.