Sprite Object Hitboxes Offset / Off Center

GDevelop general Bugs reports
#1

Greetings,

I was creating a weapons test room with a ghastly color scheme and noticed there seems to be an issue with my hit boxes.

As you can see with the below video, the objects are not actually hitting the target sprites before being destroyed.

At first I thought it may have been an issue with me using multiple animations for that object that were not the same size, so I removed it.

The second thought was that I rotate the projectiles so maybe their hit boxes remained the same, but that was ruled as it interacts with a tiled sprite fine (see below) and it would really silly if the object’s hit box did not update with rotation as you’d be stuck with square projectiles.

Lastly I thought there may be an issue with the hitbox of the target even through I only use default hit boxes for it and the projectiles and I was hit with a yes/no to that thought.
When I first open the hit box editor, I can see that it’s offset/off center and looks like the exact area that the projectile collides with, however when I zoom it it seems to fix it’s self (shown below). I have tried setting a custom mask, however it has the same issue.

Any thoughts? Is this a bug?

Running Version: 5.0.0-beta92
OS: Windows 10 (64 bit)

#2

The mask offset happens on small sprites, but afaik, it’s just a visual/zoom issue.

#3

Yea, that looks like the case.

It seems that when the sprite is moving quite fast (300-600) it looks like it’s being delete before reaching it’s target (slowed down it does).
The solution I have for now is adjusting the hitbox to 75% normal size so the front 25% does not have one, gives the illusion a little better.

#4

Maybe, from a pure visual aspect, you could solve this by scaling up your game assets?

So if the issue is due to them being tiny, just scale all of your assets to 2x or 3x their current size?

#5

Well, if the speed it moves in one frame makes it reach the target, then it won’t show in that frame because it does: move object-collision detected-delete object-display frame (unless perhaps if you move the delete action above the movement action, you should get an extra frame).
Good if you found a fix. I guess you could also use a timer for object deletion, or stop the object and reduce opacity…

But why on your gif, it sometimes seems to be deleted way too early, like half-way? :confused:

#6

It’s less about their size as its only really a visual “glitch” in the hitbox editor when not zoomed in. I think Grunk nailed it below.

#7

That makes 100% sense when it comes to the frame movement. Having the delete above the moment might be the best way to approach it if possible, otherwise I guess I’ll have my own Oprah moment. “You get an object timer and you and you and you”

I would not trust that .gif much, it’s Gyazo. I’d be lucky if it recorded the area in > 30 fps. So it’s more than likely skipping a lot of frames.

Edit: Just tried a different approach. Because my projectiles already have object variables attached to them (for damage etc) I just added a test “hasHitTarget” one that switches to 1 once it has collided. That along with setting the hitboxes back to normal has fixed it :slight_smile: Hitting perfectly now :smiley:

1 Like