Page 1 of 3

### Rotating room collision.

Posted: Sat Apr 28, 2018 1:56 pm
Does anybody know how collision was done in rotating rooms in games? I was thinking about doing a transform on the character's coordinates first, run the collision, then do the reverse transform, but I realized that doing two transforms will ruin precision. So I would need to save the "screen space" coordinates in case the character doesn't collide. There is still a problem with that. Sloped tiles have no effect on x velocity under normal circumstances, whereas doing collision inside a rotating play field would. Would I just ignore this little physics inconsistency between a sloped tile on a flat play field and a flat tile on a sloped playfield?

### Re: Rotating room collision.

Posted: Sat Apr 28, 2018 3:41 pm
psycopathicteen wrote:Does anybody know how collision was done in rotating rooms in games? I was thinking about doing a transform on the character's coordinates first, run the collision, then do the reverse transform, but I realized that doing two transforms will ruin precision. So I would need to save the "screen space" coordinates in case the character doesn't collide. There is still a problem with that. Sloped tiles have no effect on x velocity under normal circumstances, whereas doing collision inside a rotating play field would. Would I just ignore this little physics inconsistency between a sloped play field and non sloped play field?
How about doing everything in non-rotated space and apply the rotation as a final “camera effect”, so to speak. Then the only thing that would need to be rotated on the game logic side of things is the gravity vector...

### Re: Rotating room collision.

Posted: Sat Apr 28, 2018 6:59 pm
Not to mention that your character's hit box will not match the character's visual representation at all...

### Re: Rotating room collision.

Posted: Sat Apr 28, 2018 7:56 pm
Espozo wrote:Not to mention that your character's hit box will not match the character's visual representation at all...
Yeah, I'd need to somehow switch vertical and horizontal collision around when it hits a certain place.

I have an idea. I already keep an old copy of x and y positions so that the collision routine knows where the object came from. I can use that information to recalculate the objects movement before applying collision, and then calculate screen coordinates. I would need to make the object slots slightly bigger again.

I might just implement a rotating platform before I tackle doing an entire rotating room, since my next boss fight will involve a rotating platform, and I haven't even gotten to drawing the giant robot yet.

### Re: Rotating room collision.

Posted: Sat Apr 28, 2018 8:43 pm
Yeah, moving the coordinates of everything around a certain point seems like the best solution, but introduces plenty of other problems. Does anyone have any idea how 3D games do collision? It's probably totally irrelevant to this though, because they have something just a bit more powerful than an approximately 3MHz 65816...

### Re: Rotating room collision.

Posted: Sat Apr 28, 2018 11:47 pm
Espozo wrote:Yeah, moving the coordinates of everything around a certain point seems like the best solution, but introduces plenty of other problems. Does anyone have any idea how 3D games do collision? It's probably totally irrelevant to this though, because they have something just a bit more powerful than an approximately 3MHz 65816...
Always collide in World Space, and just move the camera to create local space. Very rarely does one collide in Screen space.

psycopathicteen - is this a mode 7 rotation?

### Re: Rotating room collision.

Posted: Sat Apr 28, 2018 11:52 pm
3d collision is always in 3d space, so orientation is irrelevant. The basic unit is a ray, a line from this point to that point. Does it hit anything?
Then forms like boxes, spheres and ellipses are done on top, or with inner magic.

If you mean which way transformations go, everything is in world space. If the player's box gets rotated, then it gets rotated, but the world doesn't.

### Re: Rotating room collision.

Posted: Sun Apr 29, 2018 12:55 am
The backbone of 3D is the matrix transform, which includes arbitrary rotation, among other transformations. Actually this matrix can contain a whole chain of them baked into a single matrix with an interesting trick.

It's predicated on being able to multiply, though. That's the big bottleneck for older systems like this, I think.

You can do all the same transformations in 2D, just with a matrix that's one column/row smaller (or ignored, as is usually the case with using modern hardware already built around 3D support).

If all you need is a rotation though, the basic unit of work is 4 multiplies and 2 adds per X,Y coordinate. If you're talking SNES, your mode 7 background is already doing this inherently for your background, and you just need to do that transform for your sprites. (Like others said, collision is done before the transform, the transform is just a "camera" thing.)

### Re: Rotating room collision.

Posted: Sun Apr 29, 2018 3:23 am
rainwarrior wrote:It's predicated on being able to multiply, though. That's the big bottleneck for older systems like this, I think.
Probably why in Super Castlevenia IV there's no ennemies while the room is rotating, only when it's at 90° angle, so only the player's coordinates have to be transformed against the background.

Super Mario Kart had to use the DSP-1 in order to do a lot of multiply operations per frame.

### Re: Rotating room collision.

Posted: Sun Apr 29, 2018 5:26 am
Well, there's workarounds, too. Like if you had a bunch of things on a grid you can rotate an offset vector once and just reuse that between items in the grid. Or you could have enemies confined to concentric circles, etc.

Contra III seems to have quite a few moving objects during its top-down freely rotating segments, and I don't think it had any add-on chips?

### Re: Rotating room collision.

Posted: Sun Apr 29, 2018 6:13 am
I came up with a math equation to eject objects straight vertically and horizontally so that the physics work the same both ways.

X = Ax + By
Y = Cx + Dy

popping y:
(Y - Cx)/D = y

popping x:
(X - By)/A = x

I haven't figured out how to do slopes while rotated though.

### Re: Rotating room collision.

Posted: Sun Apr 29, 2018 6:42 am
Circle collision is circle collision no matter how much the circles are rotated. And it needs zero multiplies if you have a suitable lookup table or the objects' radii are suitably constrained.

Code: Select all

``````xdistance = abs(x[oneobjid] - x[otherobjid])
ydistance = abs(y[oneobjid] - y[otherobjid])
and squared[xdistance] + squared[ydistance] < squared[sum_of_radii]):
log_collision(oneobjid, otherobjid)
``````

### Re: Rotating room collision.

Posted: Sun Apr 29, 2018 6:54 am
psycopathicteen wrote:I came up with a math equation to eject objects straight vertically and horizontally so that the physics work the same both ways.
Well if your rotation matrix coefficients are A B C D:

Code: Select all

``````A B    cos a  sin a    A B
=               =
C D   -sin a  cos a   -B A``````
If you wanted to invert that to make vectors that are straight vertical/horizontal after the rotation, you can just invert the angle, which just means you swap B with -B in the result. (because: cos a = cos -a, sin a = -sin -a)

So going back and forth between the pre-rotation space and the post-rotation space is just the same transform with that one sign flipped.

Your inversion with the division isn't wrong, I don't think, but there's an easier way.

### Re: Rotating room collision.

Posted: Sun Apr 29, 2018 7:04 am
Making the hitbox of everything a circle has been brought up, but would it be at all feasible to check a rotated box against the collision map?

### Re: Rotating room collision.

Posted: Sun Apr 29, 2018 7:08 am
rainwarrior wrote:
psycopathicteen wrote:I came up with a math equation to eject objects straight vertically and horizontally so that the physics work the same both ways.
Well if your rotation matrix coefficients are A B C D:

Code: Select all

``````A B    cos a  sin a    A B
=               =
C D   -sin a  cos a   -B A``````
If you wanted to invert that to make vectors that are straight vertical/horizontal after the rotation, you can just invert the angle, which just means you swap B with -B in the result. (because: cos a = cos -a, sin a = -sin -a)

So going back and forth between the pre-rotation space and the post-rotation space is just the same transform with that one sign flipped.

Your inversion with the division isn't wrong, I don't think, but there's an easier way.
I thought about that, but I realized the character's running speed would be wrong. I'll show a drawing of what I mean by it.