Sorry your browser is not supported!

I'm creating a Tetris game as part of a school project using Dark GDK.
Currently I want a falling piece to rotate when the user presses the up and down keys. Thus far my attempts have been futile in formulating an algorithm to do this.

I've had two ideas:
1) Manually set the position of each block making up the falling piece depending on the type (there are 7 types of pieces in Tetris, and each is made up of 4 blocks (4 sprites of the same image))
2) Rotate all four blocks using dbRotateSprite()

The problem:
I don't know any functions that can manually reset the position of the sprites, and I don't want to delete them and create new sprites... lest take up too much memory
I have absolutely no idea how I can set up a center point for the entire piece to rotate on.

If anyone has any ideas for how I can tackle this problem, or know a function that can relocate the position of a piece without having to move the sprite, I would greatly appreciate it.
If more information about my code is needed, please tell me.
Thank you.

Hey ROF how are you setting up your playing field??

Perhaps you can use a multidimensional array of bools. Like 0 is empty space and 1 is filled by a block.

bool field[15][9]; "perhaps?"

IDK just a thought

Well that's a good point... I haven't exactly set up a playing field... I've avoided the problem of having the blocks end up halfway or off screen by limiting their movements to 30 pixels at a time, because they are 30x30 blocks, and by making invisible walls

I haven't tried an array of bools, but I could try. Thanks for the suggestion.

I'm wondering where you are at with your project. Is it due?

I feel like I could help you more.

Like code some small samples or something that would be helpful.

I... Love... Tetris!

Alright, I'd REALLY like to help you with this (I know how much deadlines can SUCK, especially for a school project).

There is a distinct order to how Tetris logic is executed. First, a block is created at the top of the screen, i.e. a group of blocks treated as a single entity. Here, it's just a matter of keeping the shape intact and moving down bit by bit. Once it hits something, it is no longer active. It simply rests on whatever it hits. Then, the system checks for any completed horizontal lines. If any are found, those chunks are removed and everything ABOVE the removed lines act upon their physics and fall down (You could make this REALLY interesting if you had multicolored "clusters" that stuck together). Score is calculated and the logic loops.

Once you examine the core functions, it shouldn't be too hard to write the code for the game.

Now to the rotation query:
As most shapes only has 4 distinct forms when rotated (The I-block has only 2, and the Cube-Block has only 1), as BenJames8 stated, they can easily be represented by a 4x4 array of boolean values. The classic L-block could be represented as:

0100 0000 1100 0010
0100 1110 0100 1110
0110 1000 0100 0000
0000 0000 0000 0000

The only logic that needs to be performed is, in essence, the active block in motion. Each shape generally rotates on the axis of the second block of the second row:

0000
0X00 <-That one right there...
0000
0000

It'd probably be easiest to hold each shape and each rotation in memory as native boolean arrays, and use a value (1-4) to calculate which rotation of the active block to display, as well as a value to calculate which block is to be displayed.

Let me know if there's anything I can do to help out more!