It is currently Mon Jan 21, 2019 9:23 pm

 All times are UTC - 7 hours

### Forum rules

• For making cartridges of your Super NES games, see Reproduction.

 Page 1 of 3 [ 37 posts ] Go to page 1, 2, 3  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Rotating room collision.Posted: Sat Apr 28, 2018 1:56 pm

Joined: Wed May 19, 2010 6:12 pm
Posts: 2790
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.

Top

 Post subject: Re: Rotating room collision.Posted: Sat Apr 28, 2018 3:41 pm

Joined: Thu Feb 07, 2013 1:15 am
Posts: 116
Location: Sweden
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...

Top

 Post subject: Re: Rotating room collision.Posted: Sat Apr 28, 2018 6:59 pm
 Formerly Espozo

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3423
Location: Richmond, Virginia
Not to mention that your character's hit box will not match the character's visual representation at all...

Top

 Post subject: Re: Rotating room collision.Posted: Sat Apr 28, 2018 7:56 pm

Joined: Wed May 19, 2010 6:12 pm
Posts: 2790
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.

Top

 Post subject: Re: Rotating room collision.Posted: Sat Apr 28, 2018 8:43 pm
 Formerly Espozo

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3423
Location: Richmond, Virginia
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...

Top

 Post subject: Re: Rotating room collision.Posted: Sat Apr 28, 2018 11:47 pm

Joined: Tue Feb 07, 2017 2:03 am
Posts: 644
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?

Top

 Post subject: Re: Rotating room collision.Posted: Sat Apr 28, 2018 11:52 pm

Joined: Tue Oct 06, 2015 10:16 am
Posts: 874
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.

Top

 Post subject: Re: Rotating room collision.Posted: Sun Apr 29, 2018 12:55 am

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7111
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.)

Top

 Post subject: Re: Rotating room collision.Posted: Sun Apr 29, 2018 3:23 am

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7649
Location: Chexbres, VD, Switzerland
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.

Top

 Post subject: Re: Rotating room collision.Posted: Sun Apr 29, 2018 5:26 am

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7111
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?

Top

 Post subject: Re: Rotating room collision.Posted: Sun Apr 29, 2018 6:13 am

Joined: Wed May 19, 2010 6:12 pm
Posts: 2790
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.

Top

 Post subject: Re: Rotating room collision.Posted: Sun Apr 29, 2018 6:42 am

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21007
Location: NE Indiana, USA (NTSC)
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:
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)

Top

 Post subject: Re: Rotating room collision.Posted: Sun Apr 29, 2018 6:54 am

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7111
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:
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.

Top

 Post subject: Re: Rotating room collision.Posted: Sun Apr 29, 2018 7:04 am
 Formerly Espozo

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3423
Location: Richmond, Virginia
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?

Top

 Post subject: Re: Rotating room collision.Posted: Sun Apr 29, 2018 7:08 am

Joined: Wed May 19, 2010 6:12 pm
Posts: 2790
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:
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.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 3 [ 37 posts ] Go to page 1, 2, 3  Next

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 4 guests

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

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki