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.

AppGameKit Classic Chat / POSSIBLE BUG : GetSpriteHit() not returning correct sprite number?

Author
Message
hakimfullmetal
9
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 20th Jan 2016 05:40 Edited at: 20th Jan 2016 06:40
Link
Hello everybody. I just noticed some strange behaviour regarding GetSpriteHit(), but I'm not sure what is causing it.

I have set up a background sprite, a player sprite, and an obstacle sprite
The player and obstacle sprite depth is above the background sprite.

I called GetSpriteHit() to detect if the specified world coordinate is hitting the sprite.
Initially, without any input, the GetSpriteHit() detect the obstacle sprite just fine.

But, as soon as I move the character sprite, the GetSpriteHit() was unable to detect the obstacle sprite. It can only detect background sprite
Even if I used fixed coordinate for the obstacle sprite , it still did not detect my obstacle sprite after I move the player.
I tried moving the viewOffset at the beginning without moving the character, and it can detect the obstacle.

I have absolutely no idea of what's going on. I did not do anything else except moving the player, which had nothing to do with the obstacle position.
So why GetSpriteHit() unable to detect the obstacle?

Any help is greatly appreciated. Thanks . Here's the project folder if you want to test it:

Move that dark square representing the player unsing WASD keys. The other same unmovable dark square to the left of the player is the obstacle.

Attachments

Login to view attachments
Back to top
Profile PM
hakimfullmetal
9
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 20th Jan 2016 07:16 Edited at: 20th Jan 2016 07:19
Link
I've done some testing.

Apparently, the problem had something to do with GetSpriteCollision( , ) interacting weirdly with GetSpriteHit().

If GetSpriteCollision( , ) is called after GetSpriteHit(), GetSpriteHit() will not detect sprites correctly.
When I used both of them in my project, GetSpriteHit() only detect the background sprite.
When I commented out all GetSpriteCollision( , ) commands, the GetSpriteHit() detects sprites correctly.

But that's all that I can figure out in Tier 1. Need AppGameKit developer help to confirm it.
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 20th Jan 2016 11:56 Edited at: 20th Jan 2016 11:58
Link
??? same depth
SetSpriteDepth (player, 5 )
SetSpriteDepth (obstacle, 5 )

GetSpriteHit using a depth sort, means try different depth.

else u can use also
GetSpriteHitCategory ( categories, x, y )
GetSpriteHitGroup ( group, x, y )
GetSpriteHitTest ( iSpriteIndex, x, y )
AGK (Steam) V2.0.16 : Windows 10 Pro 64 Bit : AMD (15.30.1025) Radeon R7 265 : Mac mini OS X 10.10 (Yosemite)
Back to top
Profile PM Email
hakimfullmetal
9
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 20th Jan 2016 13:34
Link
What I'm trying to do is trying to detect if any sprites (except the background sprites ) will hit the player sprites if player move to new position. And if something hits the player, I wanted to know which sprite.
I wanted to avoid checking each and every sprite for collision against the player (which will need to be done if I'm using GetSpriteHitTest ( iSpriteIndex, x, y )), so I can only use GetSpriteHit()
I have solved this problem temporarily by avoiding the use of GetSpriteCollision( , ). So I can only use the GetSpriteHit() command for now.

I did not try to use GetSpriteHit to test for player sprite. I use it to check for other sprites except background sprites
I also tried to use different and same sprite depth for the player and obstacle, but the problem still persists
I also did not categorize or group the sprites using the sprites physic command. I did not use physic for the sprites.

GetSpriteHit is supposed to be detecting the uppermost sprite, which means it's supposed to detect the obstacle sprite at all time, and not the background sprite.
In that project, obstacle sprite is depth 5, and backgorund sprite is depth 10. So its supposed to detect the obstacle sprite at any given time.
I also tried to arrange so the obstacle depth is lower than the background, but GetSpriteHit did not detect the obstacle at all, even at the beginning.

GetSpriteHit() did successfully detect the obstacle sprite if it's used by its own.
However it immediately fails to detect the obstacle sprite if GetSpriteCollision( , ) is called.
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 20th Jan 2016 15:49 Edited at: 20th Jan 2016 15:57
Link
try using a spritehit test from the middle, not at the edges.
means if u make a hittest at x=20 but the sprite is at x=20.00000001 the test fail because its not inside.


GetSpriteXByOffset( player )
GetSpriteYByOffset( player )

my test:
AGK (Steam) V2.0.16 : Windows 10 Pro 64 Bit : AMD (15.30.1025) Radeon R7 265 : Mac mini OS X 10.10 (Yosemite)
Back to top
Profile PM Email
hakimfullmetal
9
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 21st Jan 2016 09:04
Link
Thanks, that could solve it too.

But still, GetSpriteHit() will still be bugged if GetSpriteCollision( , ) is used.
Back to top
Profile PM
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 22nd Jan 2016 16:19
Link
The problem is that by default sprites have no collision shape, so GetSpriteHit falls back to just checking the bounds of the sprite. When GetSpriteCollision is first called it notices there is no collision shape and generates a box shape for it, which by default is the same as the sprite bounds. Now when GetSpriteHit is called it sees the sprite has a shape and uses that to test instead. It turns out that there is a very slight difference in the two methods of checking in GetSpriteHit, if the point is right on the edge of the sprite then the first method records a hit whilst the second doesn't. Since the second method is coded into the physics system the only way I could make the two line up would be to make the first method also return no hit, but that doesn't help you in this situation.

To solve this problem I would change the point you are using to check. Currently you are using GetSpriteX() which returns the top left corner of the sprite, so this point will always be on the very edge of the sprite. Instead if you check GetSpriteXByOffset() it will use the center of the sprite which is much more reliable for collision checks. You can also use SetSpritePositionByOffset to position a sprite by its center point.
Back to top
Profile PM Email
hakimfullmetal
9
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 25th Jan 2016 05:53 Edited at: 25th Jan 2016 05:57
Link
I see. So as Markus said it was a problem of sprite bound.

Just wanted to clarify, is this what happened?
1 - GetSpriteHit detect collision at the obstacle (zero offset) using the bound of the sprite (size 16x16)
2 - GetSpriteCollision called, notices there is no collision shape, so generates a new collision box, but failed to detect collision at the specified coordinate which was used for GetSpriteHit (because of new collision box bounds)
3- GetSpriteHit called again later in the next loop, it sees a shape (which was generated by GetSpriteCollision before), and continue to fail to detect collision.

If the above is true, can we make it so that GetSpriteCollision also falls back to just checking the bounds of the sprite (like GetSpriteHit did) , instead of generating a new box?
(Or would that mess up the physics too?)
Back to top
Profile PM
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 25th Jan 2016 19:02
Link
You are correct.

Quote: "can we make it so that GetSpriteCollision also falls back to just checking the bounds of the sprite (like GetSpriteHit did) , instead of generating a new box?"

Unfortunately GetSpriteCollision requires a shape to do its calculation, so this is not possible. I would recommend using a point that isn't on the edge of the sprite instead.
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-25 11:52:20
Your offset time is: 2024-11-25 11:52:20