Anchor points and collision.

[Dream Of Sleeping]

Hello. I was looking into the easeljs framework and I wanted to flip an image so it faced the other way. To do this I had to set it's regX and regY property to the center of the image and then set the scaleX to -1. This then changes the x position to the center of the image. I thought this seemed really strange, although I'm not yet in a position to know what is strange and what the norm.

 

So, I was looking into pixijs and this does the same thing. Instead its called anchor.x. As I think both frameworks are little based on a flash type of framework, this must be a pretty common way of doing things so I was wondering...

 

Where do you prefer your anchor poiints? And if you like it in the middle how does this affect what type of collision detection you use?

 

I want to just started dong bounding box collision but with the anchor point being at the center that kind of messes up every example of this type of collision dection I've seen. The rectangle interesects methods I've seen would no longer work for example.

 

If you you prefer your anchor point at the top left, then how do you flip images for your sprites in animations? Or do you reverse your image the in an image editor first?

[rich]

Phaser uses the same system too - you specify what I call the 'origin' and scaling and rotation is based around that. In Flash it was called the "Registration Point", hence the regX/regY in easeljs.

 

The trick to it is that you don't use the origin to calculate your bounding box from, but you maintain those bounds separately to the origin. So you'd have something like a Rectangle object that is used to wrap the object entirely, regardless of what the origin has been set to. At it's most basic if the origin was the middle of your sprite, then the bounding box would just be the same as before, but you offset the top x/y of it by half the width/height of the sprite. If you want to support the bounding box fitting around any object even when rotated, that's a lot more math I'm afraid (not massively complex, but not easy to explain without giving lots of code examples).

[Dream Of Sleeping]

Thanks. It came to me last night, that that would be a good way of doing it. It's still good to have comformation that its the standard way of doing things. I don't need to calculate it's bounds when it's rotating. Thankfully!

[Dream Of Sleeping]

It turns out that very recently easeljs has added a getBounds() method. It doesn't work how I would have thought. The x and y coordinates never change even when the bitmap is being moved. It's always just a number that is relative to the anchor point.

 

To me this seems odd, but again maybe I'm missing something. But if I were to implement my own getBounds method it would return the current position of the object on the canvas. Do you think  the easeljs way is a standard way of doing things?

[rich]

Bounds should really be thought of as the dimensions of the object after translation has taken place, not the location of it, but I can see why you'd be confused over it as it's by no means consistent between frameworks.

[Dream Of Sleeping]

Ok so this is getting confusing. So how do you work out if it's hit other things? Should I just use the anchor point and the bounds.x and y to calculate the actual position on the stage? Then form a new rectangle and then use THAT rectangle to pass to a rectangle interects method?

 

I don't see what use it is knowing the bounds other than to see how it interacts with other objects. 

[rich]

Well you know the anchor point, the x/y coordinates and the bounds. You've all the parts you need to perform any AABB collision with anything. You need the bounds specifically for the collision phase.

[Dream Of Sleeping]

Why do you need the bounds specifically for the collision phase? Is it just in case you have altered the bounding box to be a tigher fit or changed it in some way so not all the visible sprite is collidable, or it for some other reason?

 

Sorry if I'm asking too many questions. I can always get things to work, just fine, but learning conventions when you don't know anyone who writes code is quite difficult. I've google a lot about sprite and bounds triyng to other frame works methods.

[rich]

You could easily get by with just one bounds property for an object that is entirely calculated in world space. So long as every object is done in the same way this approach is fine for simple collision checks and is fast. It works fine for normal rect-rect intersection and also fits into a quadtree really well. If you want to get into more advanced collision it starts to break down though.

[Dream Of Sleeping]

Ok. Thanks. Maybe I should just do it this way until I come across something that I can't do. Then when that happens it might shed some light on why it's useful for the bound rectangle x and y not to change with the movement.