Tetris Rotation Problem

This topic is 1937 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

So, I'm programming Tetris at the moment. I researched around on how people approached their design of Tetris. That's when I came upon this article. The one part I got stuck on was the explanation of rotating a piece. It reads:

Next, we compute the new location. Our goal is to keep the center of the falling piece constant (or, given that this is not possible if we have an even number of rows or columns, to keep the center as constant as possible). Keeping the center of the falling piece constant during rotation is the most difficult part of Tetris, so read this part very carefully (though that is always good advice!). Besides making rotation more intuitive, we want to keep the center constant so that if we rotate around and around, the center does not "drift" -- a full 360 degree turn should bring us back to where we started. To meet these conditions, we observe that we just need to adjust the left column and top row of the falling piece by subtracting half of the change in the size of each dimension that results from each turn, where the change in the size of each dimension equals the difference between the number of rows and columns (though you have to think about whether this difference should be positive or negative). Read and re-read the preceding paragraph. Draw pictures. Make sense out of it. When you finally convert it into Java, you will find there are two simple lines that make rotation-about-a-fixed-center work:
fallingPieceRow -= <something>;
fallingPieceCol -= <something else>;[/quote]

Doing as he said, I've been writing and drawing stuff for an hour, and I still haven't figured out what he means. Is he referring to subtracting the half of "change in size" from the top left most cell of each piece to keep the center orientated throughout rotations? I'm having trouble wrapping my head around what he meant.

Share on other sites
I don't understand it either. I'm not sure why it needs to be that complicated. Just pick one square of the piece to be the center of rotation, and go from that.

Share on other sites
He is poorly explaining that section.
When he says, "subtract half the change in size of each dimension that results from each turn" He means...

For my example, imagine the 'T' piece.
" the size of each dimension"- for the T piece, it is 3 squares across (the x dimension) and two squares up-and-down (the y dimension)

If you were to rotate the T piece clockwise, so the part currently sticking down is sticking out to the left, it would be flipped to 2 squares across (x) and 3 squares up-and-down (y)

The change in size for each dimension is then 3-2=1 (X dimension)
2-3 = -1(Y dimension)
half the change in size: 0.5(X Dimension)
-0.5(Y Dimension)

At least, thats what it seems like he's saying to me. I'm actually not sure how that helps, and like he says, " you have to think about whether this difference should be positive or negative."

Share on other sites

I don't understand it either. I'm not sure why it needs to be that complicated. Just pick one square of the piece to be the center of rotation, and go from that.

This is what i did when i made tetris, i played some games of tetris, and just watched for what square was being used for rotations, it's pretty straight-forward imo.

Share on other sites
I assumed there was some logic behind it, mainly because what happens when there's a variable set of rows and columns for each piece, aka custom pieces. Normally, it would be easy to say "choose this center block," but I figured he was explaining it because when you do rotate a piece, it ends up in the same spot, but not using like a single cell of the array.

Share on other sites
I preferred a source that described the game itself. Search for section 5.3 on this page: Link It helped me a lot.

Share on other sites

I preferred a source that described the game itself. Search for section 5.3 on this page: Link It helped me a lot.

This is actually very helpful. Thank you!

Share on other sites

I made a quick video tutorial that explains how to rotate a tetris block with matrices. I hope you find it hepful:
I recovered my password and spent lots of time trying to retrieve my old account here just to say that that video tutorial of yours is really well done and helpful! GJ!

Share on other sites
x = x*cos(angle) - y*sin(angle);
----------------------------------------
y = x*sin(angle) + y*cos(angle);

It's pretty hard for a lot of people because it involves Algebra, and we all know that many people prefer to only touch Algebra with a ten foot long stick.

I'll try and explain the situation as best as I can using C++ and SDL as an example, but the problem is the same in any library/language:

First, you might want to try and center the X and Y coordinates of the focus block(the block that's currently falling and you're moving):

 int Xcenter; int Ycenter; 

Next, you can try and implement a median (the distance from the center of the focus block to its sides ) like this:

 Xcenter -= MEDIAN * 2; Xcenter += MEDIAN * 2; Ycenter += MEDIAN * 2; 

Then, you can use a coordinate variable (e.g. int x, int y, int x1, int y1, etc.) to call a function (accessor) to return the center of the square, and position it at its origin:

 x1 = Xcenter; y1 = Ycenter; 

Then, perform the rotation like follows:

 x2 = - y1; y2 = x1; 

Make the necessary adjustments to your control, engine, etc. to change the image in memory of the rotation angle by the 90 degrees or -90 degrees as necessary, and you can get your original location like:

 x2 = Xcenter; y2 = Ycenter; 

Of course, there's a bit more to it than just that. You can't expect to rotate an L-block without pre-checking to see if there's a collision at the position, and without not knowing the positions in any sense, or else you'd expect a creepy little bug.

But you said rotation was your problem. The solution I enlisted shows you how to fix a median from a centered image, and then rotate negative or positive, and move around the center of the origin.

Of course, again, someone not being so sufficient in math would probably gain very little from this.

But it's basically a rotation of four 90 degree angles. Whatever you ultimately can put together is up to each person.

If it works, it works. Those are the basic steps. Cleaning up messy code, working on memory use, and fixing small bugs can done progessively through the production, but testing a well-working program always should be satisfactory. Edited by Pointer2APointer

Share on other sites

I recovered my password and spent lots of time trying to retrieve my old account here just to say that that video tutorial of yours is really well done and helpful! GJ!

Heh, thanks.

Share on other sites

I made a quick video tutorial that explains how to rotate a tetris block with matrices. I hope you find it hepful:

[media]
[/media]

Sorry for getting to this late. But that was very informative. That's exactly what I needed. I'll get back to you guys on my progress.

@pointer: Your solution works, too. It's mostly helps without having to do an exception case of if the block is a 2 x 2 square, then there won't be a rotation at all. Visual, anyway. Edited by Zido_Z

Share on other sites

I preferred a source that described the game itself. Search for section 5.3 on this page: Link It helped me a lot.

Indeed. Rotating Tetris pieces doesn't need "general" algorithms, only a table of how each actual piece rotates. It is the heart of the game, and it has to be perfect: for example, if rotating an O piece, an horizontal I piece twice, or a S,Z,L,J,T piece four times in the same direction shifts it left or right we are playing a major variant, not standard Tetris.

Transform matrices might be a good idea (depending on the game engine architecture in use), but they are only useful to implement the desired piece moves, not to design them.

Share on other sites

Indeed. Rotating Tetris pieces doesn't need "general" algorithms, only a table of how each actual piece rotates. It is the heart of the game, and it has to be perfect: for example, if rotating an O piece, an horizontal I piece twice, or a S,Z,L,J,T piece four times in the same direction shifts it left or right we are playing a major variant, not standard Tetris.

Transform matrices might be a good idea (depending on the game engine architecture in use), but they are only useful to implement the desired piece moves, not to design them.

Part of my reason for using it was to lay out all the rules and moves and allow me to come up with how I wanted to implement them. The state space is small enough you could just save each rotation and move between them, using checks to see if the new move would be possible or not.

Share on other sites
I recently challenged myself to make a tetris game in one day, using XNA. I too spend a lot of time trying to figure out how to rotate the pieces, but I came to the conclusion that it was overkill for such a simple game. I went with hardcoding each possible rotation for the pieces, which isn't that much (Four rotations for L, J and T, Two for S, Z and I, and none for the O).

If you want to calculate rotations because you want to learn how to, it's a good idea- If not, I would consider it overkill.