Rotating room collision.

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Rotating room collision.

Post by psycopathicteen » 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?
Last edited by psycopathicteen on Sat Apr 28, 2018 7:16 pm, edited 1 time in total.

Optiroc
Posts: 129
Joined: Thu Feb 07, 2013 1:15 am
Location: Sweden

Re: Rotating room collision.

Post by Optiroc » 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...

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Rotating room collision.

Post by Drew Sebastino » 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...

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Rotating room collision.

Post by psycopathicteen » 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.
Last edited by psycopathicteen on Sat Apr 28, 2018 9:01 pm, edited 1 time in total.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Rotating room collision.

Post by Drew Sebastino » 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...

Oziphantom
Posts: 774
Joined: Tue Feb 07, 2017 2:03 am

Re: Rotating room collision.

Post by Oziphantom » 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?

calima
Posts: 1016
Joined: Tue Oct 06, 2015 10:16 am

Re: Rotating room collision.

Post by calima » 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.

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Rotating room collision.

Post by rainwarrior » 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.)

User avatar
Bregalad
Posts: 7766
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Rotating room collision.

Post by Bregalad » 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.

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Rotating room collision.

Post by rainwarrior » 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?

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Rotating room collision.

Post by psycopathicteen » 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.

tepples
Posts: 21750
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Rotating room collision.

Post by tepples » 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])
sum_of_radii = type_to_radius[obj_type[oneobjid]] + type_to_radius[obj_type[otherobjid]]
if (xdistance < sum_of_radii
      and ydistance < sum_of_radii
      and squared[xdistance] + squared[ydistance] < squared[sum_of_radii]):
    log_collision(oneobjid, otherobjid)

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Rotating room collision.

Post by rainwarrior » 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.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Rotating room collision.

Post by Drew Sebastino » 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?

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Rotating room collision.

Post by psycopathicteen » 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.

Post Reply