Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / Sprite overlap is not a overlap but a Collision

Author
Message
Game_Code_here
User Offline
Joined: 2nd Jun 2020
Location:
Posted: 5th Jul 2020 01:04 Edited at: 5th Jul 2020 01:26
My sprites are not overlapping, just right next to each other

so why does this cause Collision ? There not touching lol.

If you are wondering, im trying to switch cell information if both sprites collide. But the selected sprite is colliding with all sprites surrounding it even if it just sits there.

Virtual Nomad
Moderator
14
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 5th Jul 2020 02:11 Edited at: 5th Jul 2020 03:56
i've seen similar and i think it's to do with floating point (in-)accuracies and perhaps how some CPUs differ. or, maybe i just don't know what i should expect

but, please learn to provide a code example that demonstrates the issue(s) where the code you've posted doesn't help others help you, at all. you've basically said "GetSpriteCollision doesn't work" above.

meanwhile, note that the sprites start "1 pixel" apart:

pressing the left-arrow key moves the right-box 1 pixel to the left, or next to but not overlapping the left-box would be the expectation where i expect the leftside to occupy pixels 100-163 on the X.

adding multiple 0000's, ie, SetSpritePosition(Spr2,164.0000000000000000,0), to try to account for "inaccuracies" is no help (for me), so, either consider it a given that NextTo = Overlap or come up with a different solution.

i ran into this when doing a game jam. i noted the odd behavior during development but i did want it to show "collide" when 1 sprite was next to another, so dismissed it (i was always "way behind" all the way up to the deadline. frantic times!). low and behold, when players started playing it, they got "no collision" and none of my dialogue prompted...

maybe someone else has advice?

just realized that they're starting "2 pixels" apart according to my own "logic" (1 px, visually). now, i've confused myself even more...
Game_Code_here
User Offline
Joined: 2nd Jun 2020
Location:
Posted: 5th Jul 2020 04:59
Virtual Nomad

Sorry, I was wrong in my testing.

I was asking for all sprites to give a collision.

So I had to define my sprite numbers like this

This post was not needed to be honest, but it is good to let people see you need to define your code better.


GarBenjamin
AGK Developer
3
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 5th Jul 2020 20:49 Edited at: 5th Jul 2020 21:01
I ran into this before and after experimenting... it seems to be the default sprite colliders are one additional pixel wide. So if the image is 64 pixels wide the collider space covers the sprite area from x=0 to x=64
However, if you add your own collider running from x=0 to x=63 which is the actual space of the sprite you will get the expected behavior.

I updated your sample to show what I mean.
The top 4 sprites in shades of red use the default sprite collider.
The collision function reports a collision for sprites 1 and 2 before they are even moved and the distance between these two sprites is reported as 0 instead of 1.
The distance should be reported as 1 because the space of sprite 1 is from x=300 to x=363 and the space of sprite 2 is from x=364 to x=427... 364-363 = 1.

The bottom sprites in shades of green use custom colliders covering the space from x=0 to x=63 and the distance and the collision are reported correctly both before and after moving expect distance actually shows about 1.9 / 0.9 pixels of space. That is reasonable considering floating point.

But basically my "take away" is always create your own colliders if you want it to be more precise.


This is the display BEFORE moving...


This is the display AFTER sprites 2,4,6 and 8 have been moved 1 pixel to the left.
blink0k
Moderator
7
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 5th Jul 2020 21:25
GarBenjamin
AGK Developer
3
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 5th Jul 2020 21:36 Edited at: 5th Jul 2020 21:36
You can try that but I am pretty sure I had tested that at one time too and it seemed to be more of a visual display system thing that did not effect collision checking. Very much like in my retro game fantasy computer framework all sprites are positioned using floor on their x and y positions. I think snap is basically doing the same kind of thing in one way or another.
smallg
Valued Member
14
Years of Service
User Offline
Joined: 8th Dec 2005
Location: steam
Posted: 5th Jul 2020 22:05
i mean the original snippet is checking if the sprite is colliding with itself which of course is true...
if you still have issues with sprites picking up nearby sprites while "idle" you could also check for the velocity of the sprite to pass a threshold to validate the collision - i.e. when the sprite is being moved by the player / falling etc it will have a much higher velocity than when it is idle
life's one big game
spec= i5 4ghz, 16gb ram, Nvidia 1070ti gpu

Login to post a reply

Server time is: 2020-09-30 17:13:28
Your offset time is: 2020-09-30 17:13:28