nesdev.org

In extension of rainwarrior's brilliant post, I'd like to add that it's only really a problem when you're doing world collision, and trying to enforce the function of solid walls or platforms, which is what I'm assuming is the end goal when you are talking about a "rotating room".
Comparing two individually rotated rectangles isn't really a big issue if you don't have too many objects to compare, and you just want to find out stuff like if there's a character hurting another character. However, when you want to push back an object along a rotated normal vector, things start getting pretty complex.

I'm not sure how you guys do your background collisions, but one of the reasons character-to-background collisions are so easy to do solidly on an NES or a SNES (and similar old school hardware), is that we are expecting the backgrounds to always fit into an aligned grid, meaning you can look up the nature of every single surface directly from the coordinates.

Once you're working with arbitrary polygons and floating point vectors, it becomes much more complex to make your polygons function as actual solid walls, which is why almost any 3D game ever created has some sort of glitchy way for your character to go out of bounds. Skyrim is a field day.
Now imagine doing this in a SNES game - you absolutely need some way to simplify your calculations in a subtle way that works compared to your game design. In this case, the first thing I'd look at is how much does your room actually rotate. If it never veers more than 45 degrees, that's a big advantage, as you can make floors keep acting like floors, and walls keep acting like walls. The "waving" section of the tower of Pisa in Castlevania Bloodlines is one of my favourite examples. As fas as I can tell, the floor remains as axis aligned tiles, but moved around similarly to the rotation effect itself. Also, collisions are exclusively calculated for the main character.

I'd love to see how Mohawk and Headphone Jack did it on the SNES though.

That and the racing game Cameltry/On the Ball.

Except the only thing that can collide with the background in Camelty/On The Ball (and just the only thing in general) is a 16 pixel diameter sphere. That'd be trivial to work with.

From a lot of video game blogs I can find, it seems like a popular collision technique is to have an octogon shaped collision box where each side has at least 2 collision points, but the corner of objects are ignored so objects will pop a little bit. One of the benefits is that horizontal and vertical collision work with the same rules so that flip-flopping the axis's would be easy.

The tricky part is that I didn't originally program using this method.

Espozo wrote:Except the only thing that can collide with the background in Camelty/On The Ball (and just the only thing in general) is a 16 pixel diameter sphere. That'd be trivial to work with.

Come to think of it, it's very likely that the hitbox in Mohawk & Headphone Jack is spherical.

I think I would have to avoid using floating walls that are shorter than the player.

I made up my mind. I'm not going to do a rotating level. To much work, too late in the game. I'll just use a rotating moving object for my planned boss fight.