# Tetris : Effective rotation

I rotate each piece by rotation formula. More detail, because rotation angle is 90 so :

xNew = y;

yNew = -x;


But my method has met two problems :

1) Out of box : each type of pieces is fit in square 4x4. (0,0 at under left) But by this rotation, at some case they will out of this box. For example, there is a point with coordinate (5,6) So, please help me how to fit these coordinate into 4x4 box again, or give me another formula for this.

2) at I case : (4 squares at same row or same column), just has two rotations case. but in method above, they still has 4 pieces. So, how to prevent this.

Thanks :)

You could just store the rotations in an array like you'd store your blocks, four for each block type, then just iterate over them. That way you don't have to deal with the mess you've described.

• This, a hundred times this: there may be a point to doing rotations if you plan on animating the rotation of pieces (but if you do that, be careful about where you let the user rotate pieces; it's very easy for a piece to 'get stuck' in a spot where it couldn't rotate more without clipping through existing pieces), but you should absolutely store a table of all pieces in all orientations rather than doing any sort of rotation on the fly. – Steven Stadnicki Jun 19 '12 at 19:20
• Couldn't agree more. See details here: tetris.wikia.com/wiki/SRS also see this question: gamedev.stackexchange.com/questions/17974/… – jmp97 Jun 19 '12 at 19:26

I usually use a rotation matrix to deal with rotation of the pieces. Since the rotation is always +/-90 degrees, you can create a rotation matrix with the fixed values in them and then multiply it by the current positions of each piece when rotating.

To deal with the fact that certain pieces have different numbers of rotations, I usually store a variable that says how many different rotations each piece has.

The Tetris board is a grid layout. A very simple way of understanding is that a Tetris piece is just a set number of squares that are 'filled'. In a boolean sense, a piece can be viewed as 0, or unfilled, or 1, filled. Using a grid (or tile-based) approach will prevent your blocks from ever going out of bounds and as an added bonus also simplifies collision code when you reach a bottom-collision.

Pseudo-code: You can do a check if (!grid[x][y]) block.move(direction) where grid[x][y] is a space you want to move into and block.move(direction) is an arbitrary function that adjusts your piece and map by one grid space in whatever direction is specified. In this sense, your game loop could also use block.move('down') to drop the piece incrementally and else block.stop(), game.generateBlock() for the next piece.

Using the grid method, you can easily check to see if your rotated piece will be out-of-bounds as if(x < 0 || x > gridWidth) block.move(direction), in which direction is the direction opposite of the way it would had moved out-of-bounds.

Continuing with the grid-based example, your pieces are really just a pattern of on/off as well and their rotation is displayed as so:

  ▇    ▇        ▇ ▇    ▇ ▇ ▇
▇ or ▇ ▇ ▇ or ▇   or     ▇
▇ ▇             ▇


What is illustrated just by this rudimentary artwork is that the pieces don't rotate around a central point due to the often rectangular pieces. The patterns can be stored in their boolean state easily enough, however, and you can just track which 'position' it is in and write your code to test it regardless of the orientation.

Since each piece has a finite number of patterns it can be in (4 maximum) and it is probably in your best interest to simply hard-code them in. This answer provides some code you may find inspiring: https://stackoverflow.com/a/8131337/571506

I highly recommend doing the research and learning a little linear algebra with these simple variables if there's even the slightest chance you'll move into 3D game programming. Since each piece can be stored as a matrix, you can apply simple transformations to the base 'piece matrix' to get the new pattern. This can be faked easily enough, or you can go all-out. I highly recommend doing the research and learning a little linear algebra with these simple variables if there's even the slightest chance you'll move into 3D game programming. For algorithms, check out this question: https://stackoverflow.com/questions/42519/how-do-you-rotate-a-two-dimensional-array

Tetris is an extremely well-documented game and can add a lot of skills to your 'toolbox'. Try to figure as much of it out using provided paradigms as possible while doing majority of the programming by hand and you'll find it a great to benefit in the long run.