Quote:Original post by DevFred
Am I the first one to seperate Shape and Piece into two different classes? They are clearly two distinct things.
Technically, they aren't.
The difference between shape and piece is same as between class and instance.
Class is formal definition. Instance is one version of this class.
All L pieces are the same. Whether they get rotated or not, they do not change the nature of what they are - they are still exactly the same shape, and they will always be pieces.
For example, in an RPG, a human character is just that. Entity <- Creature <- Player. There will be many humans, some tall, some short, some facing left, some right, ....
They are still the same class - PlayerObject, with its race property set to human, it's orientation to some matrix, and position to a vector.
Renderer is the responsible for loading the graphical representation, such as mesh and textures.
In case of tetris, there is no such representation, since the rendering is done by filling blocks.
For tetris I wrote long long time ago, I simply used arrays of 4x4 representing every possible rotation of every object. Each of those also had an achor point around which it was rotate.
If I did this in OO way, it would be:
class Piece { bool blocks[4][4]; int x_anchor; //(0..3) int y_anchor; //(0..3) Piece &rotate();}Piece blocks[28];
Similar to your aproach, but I don't separate shape and piece. They are functionally the same, but rotate still returns the new piece.
This aproach however doesn't allow for animated rotations some games use.
Quote:BTW I don't think representing a Shape with a 4x4 matrix is the most logical or efficient solution. A vector of four coordinate pairs seems better to me, because when you process the piece (check for collisions, insert it into the gameboard), you only have to do four operations instead of 16.
Unsigned short is optimal representation. You know it's 4x4, and each spot can either have a block or not.
You can then use bitmasking to determine collisions. This may potentially be much faster, since you would end up with very simple operations, shifts and "ands", with one single comparison at the end, possibly resulting in good pipelining.
But the above is completely absurd in case of tetris, where performance in this part is pointless.