Welcome Guest ( Log In | Register )

[ Big| Medium| Small] -



Post new topic Reply to topic  [ 6 posts ] 
    Sarkilas
  Thu Dec 20, 2012 4:47 pm
User avatar
Member


Location: Norway
I'm having some minor problems with working with rotated hitboxes on projectiles.
Let me give some information on how my hitboxes generally work:

- All projectiles have a hitbox of either of the two:
- A custom hitbox decided by custom width and height (used for projectiles that use sprites that have some glow or other effects that shouldn't be included in the actual hitbox).
OR
- A hitbox that is identical to the sprite the projectile uses.

For the second type of hitbox, there are no particular issues, but for the first type, it causes some weird problems - the reason why I consider it to be weird is because of my lack of math understanding.

Here's the code I'm using for the hitboxes and the actual visible sprites (noted as Animation):

Hitbox Property (will always be an empty rectangle if not set as the second type of hitbox)
Expand to see the code.


The actual hitbox. As shown, this will be set to the sprite's hitbox if the above hitbox returns empty.
Expand to see the code.


The GetOffset() method. I reckon this is where I am doing something wrong (since, you know, math..).
Expand to see the code.


To explain, the "Position" vector is the center point of the projectile.
However, when the sprite rotates, the actual width and height of the sprite changes, and the hitbox seems to incorrectly function when its smaller than the sprite itself.
The code for this works relatively well, but has some slight inaccuracy which I don't really want to have there.

If anyone sees any obvious mistakes in the code, I'd appreciate any pointers.

Thanks!

_________________
Well..


Top Top
Profile      
 

    Xilef
  Thu Dec 20, 2012 9:06 pm
User avatar
Staff

Big Dumb Guy

Location: UK
It looks like you're making this harder than it is, each entity has a sprite and a hit box, it may be easier to give the entity a default hit box for the entity based on sprite and then on initialisation have a function to reset the entity's hitbox, that way you don't need to muck around with calculating if it already has one.

On the collision check (should be done after every step) you can rotate the point you're checking around the centre of the collision rectangle in the opposite angle of the entity's rotation, that will give you a correct grid to do an isInsideRectangle() call, the hardest part is the rotating back but there are plenty of examples on Google


Top Top
Profile      
 

    Sarkilas
  Thu Dec 20, 2012 9:34 pm
User avatar
Member


Location: Norway
Thing is, not all actions have a sprite associated with them, and many of these sprites have outer edges that shouldn't be included with their hit box.
Thing is, if a projectile rotates, the hitbox has to rotate in the same fashion, and to make this accurate I have to figure out the width and height (on aligned planes) after the rotation has occured.

Such as if a sprite is at the size 100 x 50 when it's being fired straight up (0 degrees), it would have the dimensions of 50 x 100 when its fired to the left or to the right, and in between those angles it would gradually change between those two values. But the hit box assigned to it could be 80 x 30 which then should align from the center point. When pointing straight up this is a simple calculation:

sprite position = Effect X - Width / 2 , Effect Y - Height / 2
hit box position = Effect X - Box Width / 2 , Effect Y - Box Height / 2

Makes the hitbox perfectly centered within the sprite and creating the result that I want.
However once the sprite gets rotated, the Width and Height value is different, but the actual values stored into those properties do not.
This is where the core of the problem lies.

I feel that the code does most of what it should do, but the hit boxes are slightly inaccurate, and I just want to get that sorted out.

If I misunderstood your proposition, please do clarify in better detail so I might understand it properly. If anything simpler would do the same and result in better detection, I wouldn't say no to it!

Thanks for the reply.


Top Top
Profile      
 

    Xilef
  Thu Dec 20, 2012 11:25 pm
User avatar
Staff

Big Dumb Guy

Location: UK
I did try to explain about the rotation.

Here's code to eat.
Expand to see the code.


Hope you can make sense of that for your language here.


Top Top
Profile      
 

    Sarkilas
  Fri Dec 21, 2012 12:25 am
User avatar
Member


Location: Norway
Thanks for the code. That is probably going to be very useful.
Although, since all my angle values are always in radians, I assume the "entityAngle * 0.0174532925f" can just be changed into "entityAngle" with no conversion.

Thanks for this, looks just about right.


Top Top
Profile      
 

    Xilef
  Fri Dec 21, 2012 7:57 am
User avatar
Staff

Big Dumb Guy

Location: UK
Oh yes it should be -entityAngle so it is rotated the other direction to match the bounding box that is always in fixed position, otherwise it is sending the point further round the bounding box.

There is also probably a way to eliminate the sin and cos to improve performance, lookup tables is one but something tells me you can replace that with some thing else entirely that would perform better.


Top Top
Profile      
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 


Who is online

Users browsing this forum: No users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

We are an independent, not-for-profit game making community.
Homepage
Board Index
About Us
Downloadable Games
Free Browser Games
Games in Development
RPG Maker Support
Game Maker Support
Construct 2 Support
HBGames the eZine
Advanced RPG Maker
Site Announcements
Powered by phpBB © phpBB Group