Quote:right now I have it so it drops the blocks at random positions, and you can flip the blocks using the up arrow like in the real one. Its really frustrating though because Im not even sure how to erase the leftover image. I know I could just call a function that writes over it, but it seems that would cause problems if i move a block under another block and it ends up erasing a block that isnt its leftover image

Okay, hold everything... It sounds like your "pieces" are just raw pixel data and you are "moving" the pixels when you move a piece.

That's bad.

The screen is just a representation of some internal data. It sounds like you have no internal data from the way you describe it. Is this correct? What you'll want to do is create some data structures that represent pieces and blocks, then draw that data to the screen using SDL graphics routines. I think that's why you are having trouble.

You see, a pixel is just a colored square (and i know you already knew that). When an object "moves" it doesn't "move" pixels. It just changes the colors of the pixels that are already there. So in a game, you just paint the pixels according to the current internal state of the data that represents the game. Theoretically, you should be able to program the internal guts of Tetris and wire it up to any number of drawing APIs. You could take the same Tetris guts and make it 2D with SDL, 3D with OpenGL, or even ASCII output direct to the console ala "Hello World". Heck, you could even have a tetris game that has no graphical output whatsoever! Everything would still work, you just wouldn't see it (and would have a rather hard time playing :-)

The internal mechanics should not change at all between the different ways of displaying it. But if my assumption is correct, you have little or no internal mechanics at this point. That is what you need to work on.

(my sincere apologies if i misdiagnosed your situation)

Feel free to ask more questions and we will help you with that.