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 / GetSpriteHit returns 0 even when it's over a sprite

Author
Message
Timshark
17
Years of Service
User Offline
Joined: 30th Jun 2007
Location: Oslo, Norway
Posted: 19th May 2013 20:37
Link
When moving the pointer/mouse slowly from one sprite to another
GetSpritehit will return 0 between two sprites.




Why is this? There are no gap between the two sprites...

I never want what I know.
Back to top
Profile PM
Timshark
17
Years of Service
User Offline
Joined: 30th Jun 2007
Location: Oslo, Norway
Posted: 19th May 2013 20:58 Edited at: 19th May 2013 21:00
Link
I found out that getpointerX/getrawmousex returns a float.

So her is a test where I use float to position the second sprite at an x value of 40.0000
Even when the pointer is at the same 40.0000 getspritehit returns a zero. I use no virtual resolution in this. the inital resolution in setup is 480x480



I never want what I know.
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 20th May 2013 04:29
Link
Quote: "If you are testing a mouse or touch coordinate, remember to convert it to world coordinates using ScreenToWorldX and ScreenToWorldY."

According to the documentation, you should use the ScreenToWorldX/Y commands to convert the pointer values before calling the GetSpriteHit command.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 20th May 2013 09:51 Edited at: 20th May 2013 10:00
Link
i think its a image outputfilter/rounding.
your example from window to max. at fullhd is without a gap.
if you add at both a offset 0.01 there is no 0 sprite between.
Back to top
Profile PM Email
Timshark
17
Years of Service
User Offline
Joined: 30th Jun 2007
Location: Oslo, Norway
Posted: 20th May 2013 12:20 Edited at: 20th May 2013 12:24
Link
@Ancient Lady
No, that didn't help


@Markus
Quote: "if you add at both a offset 0.01 there is no 0 sprite between"

That works. It won't make any difference so I'll use that solution.
Thanks.

The lesson is: don't use whole numbers if you need pixel perfect control in agk. It's a little odd though. That a spritex value of 40.00 won't get a spritehit but a spritex value of 40.01 will.

I never want what I know.
Back to top
Profile PM
Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 20th May 2013 14:59 Edited at: 20th May 2013 19:26
Link
Quote: "According to the documentation, you should use the ScreenToWorldX/Y commands to convert the pointer values before calling the GetSpriteHit command."

I've never understood why it says that - surely that only applies for world sprites.

I think it's down to the coordinate system - integer positions seem to refer to gaps between pixels rather than pixels.

As demonstrated by commands like setScissor( 0 , 0 , 640 , 480 ) - which (if the pixel gap thing is not true) would give an area of 641x481.

Edit: World/Screen confusion fix
Back to top
Profile PM Email
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 20th May 2013 18:04 Edited at: 20th May 2013 18:05
Link
There seems to be something funny in the default collision shape setup because if you add these two lines it behaves as you would expect:


also works using a box shape:



this.mess = abs(sin(times#))
Back to top
Profile PM Email
Timshark
17
Years of Service
User Offline
Joined: 30th Jun 2007
Location: Oslo, Norway
Posted: 20th May 2013 21:19
Link
@baxslash
Ah. Ok. That makes more sense.
So this is maybe an unwanted behavior bug. I'm not sure how to describe it though. Maybe my snippet along with baxslash solution would be alright to send along with the bug report.

I never want what I know.
Back to top
Profile PM
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 20th May 2013 22:21
Link
Yes, just post your code with those two lines remarked out maybe?

The bug is that the default box shape does not seem to cover the full sprite. It's clearly a bug with this shape because it behaves as expected when you reset it using the box shape.


this.mess = abs(sin(times#))
Back to top
Profile PM Email
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 20th May 2013 22:48 Edited at: 20th May 2013 22:50
Link
I Always use sprite hit test that Always work for me as sprites can overlapp and still get if the sprite i want gets touched on screen.

Getsprite hit will only return true if the sprite is on top of any Close sprites that may overlapp.

Android 2.3 , ZTE Skate , 480x800 , 800 mhz , Samsung Galaxy Y , 240x320 , 832 mhz , Sony ericson arc 480x854 , 1 ghz
Android 4.0 , Dmtech 3g 9738B , 1024x768 , 9.7 inches , 1.2 ghz
Back to top
Profile PM Website
Funnell7
13
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 20th May 2013 22:50
Link
Ah ha... Thanks Bax, I was having a similar issue with my level editor. It would occasionally allow me to overlay tiles, even though I was checking for a collision before placing the new tile... Anyway, your SetSpriteShape(1,2) suggestions works a treat!
Back to top
Profile PM Email
Timshark
17
Years of Service
User Offline
Joined: 30th Jun 2007
Location: Oslo, Norway
Posted: 20th May 2013 22:57 Edited at: 20th May 2013 23:00
Link
The bug is posted.

There is a lot of workarounds for this problem now. But setting the Spriteshape is the best I think.

This kind of pixel control is not a major problem but could be difficult/impossible to debug in the long run.

I never want what I know.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-11-24 14:31:02
Your offset time is: 2024-11-24 14:31:02