Hello,

I am new to the Allegro library. I recently began putting together my first Tetris clone, and I set up a class for the shapes. One of the (currently public) data members of the class is BITMAP *images[4][2], which holds all possible rotations and a corresponding "eraser" image. I designed a public member function to set up bitmaps for the rotations of the shape. This is so that custom images can be put into the game. When I try to "create" bitmaps for the other elements of the images array to place a roated sprite in, the program crashes.

I do not understand a great deal about memory allocation and other related subjects, but I assume that there this is due to something with the compiler not being happy about a class trying to mess around with memory after the variables were already initialized. Of course, I could be completely wrong here.

Here are sections of the problematic code (again, I am somewhat new to this, so this may be very ugly):

Are there any suggestions for keeping this sort of function as part of the class, or should I just setup another function outside of the class to take a shape object as a parameter and do all of the bitmap functions there?

Thank you for any advice, criticism, etc.

Rather than answer your question, I'd more like to question your design concept. Why exactly do you need this "eraser" image? I have a feeling you aren't familiar with the concept of double buffering.

And why don't you simply rotate the images as needed during runtime? Since the rotation angles are multiples of 90 degrees, there will be almost no performance hit.

As for the actual code you posted, I can see only one problem. In the rotation for loop there are no curly braces around the if/else bodies. (does that even compile?)

Also when you do images[0][0]->w, I'd rather put some brackets in there to make sure it's obvious what exactly you are dereferencing, but I don't think that's actually a problem in your code.

Another thing you might want to do is initialize all pointers to 0 somewhere in the beginning. Just in case...

No need to give thanks in advance. When you're satisfied with the answers, just send some money.

Not terribly so, no I mean, I use a buffer to draw to the screen, but I don't understand a lot of the techniques related to it.

Hmm, I could do that. I was just under the impression that it was more efficient to assign the rotations to bitmaps.

You're right, that wouldn't compile. I actually cleaned it up a little bit when copying over from my IDE, and ended up forgetting to brace the code together. I'll edit my original post, thank you.

Good idea, thanks.

OK, then make sure you are familiar with the concept; it's one of the very basic techniques you need for game development.
The idea goes something like this. Say you want to display something on screen; the most straightforward way is to just draw it to the screen bitmap directly. This is all fine and dandy, but you get into trouble when you need to remove things from the screen, or things overlap - because the user can see everything you draw and erase.
The solution is to render your entire scene not directly to screen, but to a memory buffer (just an ordinary memory bitmap with the exact same size as the screen). When drawing is complete, you blit() the entire buffer to the screen in one go, overwriting everything that was there before. The process of scene composition (including the initial buffer clear) is hidden from the user, and there won't be any flicker.

That doesn't sound like good design to me.
Each shape should have 4 4x4 array of ints or bools, one for each possible rotation. You should draw the actual blocks based on that array at run-time, that is, iterate through the array and draw a block where it contains a "1" or "true". The bitmaps for the blocks should be stored somewhere else.

I'm surprised you're not getting a compiler error for failing to return a value at the end of the routine.

But, your problem has nothing to do with the way you're doing it, and everything to do with the fact that it's a constructor, which means if that constructor is run before you've initialized Allegro, bad things will happen. (IE: Crashes.)

Calling Allegro functions before Allegro is initialized is never a good thing.

And yes, doing all the rotations ahead of time would be faster, but uses more memory. A lot of speed considerations are like that, where the faster you want something the more memory you need to use.

And double buffering is an important thing to learn. I highly recommend you do so.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

This is tetris we're talking about here.
The amount of data here, if we use 4x4 grids of 32-bit ints (very inefficient, we could cram all that information into a single 16-bit int), each rotation takes up 7 * 4 * 4 * 4 bytes = 224 bytes. So the pre-calculation will cost us the immense amount of 672 bytes.

Actually he caches the rotated bitmaps, not the shapes themselves. I'm not sure how big the bitmaps are but I don't think they would take several megs of RAM.

Also I don't think that kind of optimizations are really needed in Tetris. Having a single variable showing the rotation in allegro degrees (0, 64, 128, 192) and using rotate_sprite everywhere would probably be much easier.

I don't like rotate_sprite for extremely simple rotations, but that's just me.

Tobias Dammers: I know that. 672 bytes in your example is still more memory, isn't it?

--- Kris Asick (Gemini)
--- http://www.pixelships.com

This much I understand. The problem that I am having with that is keeping the "resting" blocks on the screen, but being able to erase the active block, which is why I was using a corresponding "eraser" image with exactly the same dimensions as the active block.

Would it be more effective to draw inactive blocks on the buffer, blit the buffer to the screen (erasing the active), and then blit the active block to the screen instead of the buffer?

Thank you for the replies, everyone.

Clear the buffer, and draw all of the blocks, active and inactive alike, to the buffer before it goes to the screen.

std::vector may be of some use to you in this project.