Erasing Rectangle on a BItmap BG


First off I am new to the forums so hello all, second off I am a curious programmer. I work as a php/cgi/asp/ application programmer and I am learning c++ and allegro on the side for fun. After doing some reading I am curious. I see that you can remove a bitmap from screen with clear_bitmap however the only way I can see to do so is to do a rectfill with the same color background to hide it. However, I cannot seem to find a way to remove the trace of the rectangle on a bitmap can someone be so kind to enlighten me?

Thank you for your time in advance =).

Thomas Fjellstrom

technically a clear_bitmap is just a full size rectfill() call (though its implemented differently).

As a bitmap is just a chunk of memory, you can't "remove" something that was there, you can just replace it with something else.

So if you are looking for a way to "remove" a sprite before drawing it again, you have two main choices:

1. Dirty Rectangles, save the screen contents, and blit the previous contents of that part of the bitmap with the original, and blit the new sprite to where ever, or
2. Plain Double Buffering, draw everything to a "screen" sized bitmap, and blit that to the screen, every frame/loop.


Oh ok I think I understand so what you would do is draw the rectangle or bitmap to the buffer and then draw it to the screen and then remove the buffer and do all looping redraws to the buffer first correct?

Thomas Fjellstrom

exactly. Though if you fill the entire area of the buffer every frame, you don't need to "empty" it at all, saving a possibly costly "clear_bitmap" call.

psuedo code:

while(!key[KEY_ESC]) {
  // optional clear_bitmap(buffer);


That's about what I have =). Now I'm just trying to figure out how to animate a projectile, I need to find some good reading haha.


You have to understand the basic concepts in computer graphics. In computer graphics you can not erase something from a bitmap. All you can do is draw to a bitmap. If you draw a rectangle over a part of a bitmap with the same colour as the background, it will appear is if you erased whatever was there before. But yeah, you will want to use double buffering or similar 99% of the time.


Now I'm just trying to figure out how to animate a projectile, I need to find some good reading haha.

Your main loop has to have (at least) two parts: logic and code. In the logic part you have some variables that represent the state of your imaginary world (including projectiles). For a projectile you will have at least variables called something like x and y. In the logic part of your code you will update those variables according to some more or less advanced physics simulation and in response to user input. For example, when a projectile is launched (by the user pressing a certain key for example), you will create a projectile and start incrementing x and/or y by a certain value (you can call it velocity). You will then check if the projectile collides with some other object and if it does, you will make the projectile explode (destroy). This logic code will be called over and over again in a loop, preferably a fixed number of times every second (for example 100 times).

The second part of your code will be the drawing code. In this part you will draw to the screen a more or less detailed graphical representation of your imaginary world that the variables from the logic part describe. This part of the code you will also call over and over again in a loop, but separately from the logic part.


^ Was a good read, just wanted to start out with that being said.

So from what you said I did some research and saw a allegro function called getpixel(). I can see where you could use that to test if the space in front of the projecticle is a solid color. So in psuedocode it would be:

Main Loop
if key_space is hit
add projectilex++
add projectiley++
projectilex = projectilex
projectiley = projectiley
end if

Fladimir da Gorf

I wouldn't recommend using getpixel for the testing. You should separate the drawing from the game logic totally. Instead, you'll need to check if the position would hit any obstacle's bounding box or collision map.


Some more light reading for you:

A simple game is roughly constructed from the following parts:

  • initializing system environment

  • loading and preparing game data

  • main loop

  • cleaning up

The main loop in turn has three distinct parts:

  • input

  • processing

  • output

(In my last post I merged "input" and "processing" into "logic".)

Since you decided to use Allegro you can create everything listed above entirely with only functions this library provides (even though many people choose to use more specialized libraries for certain tasks). The processing part can (and should) actually be done without Allegro completely.

1. Initialization: This is a very simple task. You only call a few of the Allegro functions from the first couple of chapters of the Allegro manual and check their return values (to make sure all is working properly). The chapters of the Allegro manual you must read are: "Using Allegro", "Configuration Routines" and "Graphics Modes". You should also take a look at the functions whose name is in the format "install_something" in chapters "Mouse routines", "Timer routines", "Keyboard routines", "Joystick routines" and "Sound init routines".

2. Loading and preparing data: Here you will load bitmaps, samples, fonts, music files, levels, maps, etc. You will also create an off screen buffer for your double buffering system here. You will use functions from these Allegro chapters: "Bitmap objects", "Loading image files", "Fonts", "Digital sample routines", "Datafile routines" and perhaps several others. You will mostly call functions named something like "load_something" and "create_something". Again you will check the return values to make sure everything went fine.

3. The main loop: This is a while loop that potentially runs forever. You only break from this loop when it is time to close the program (as a response to user input). In the main loop you have three parts that are executed over and over again: input, processing and output. The code must be structured in such a way that input and processing are executed a fixed number of times each second while output can run slower (or faster if you so wish). You can accomplish this by using functions from the chapter titled "Timer routines".

3.1. Input: Here you gather player input. You check for the status of the keyboard, mouse and/or joystick(s). (In some more advanced games you would also gather incoming network data here). You should do all this with just the Allegro functions from chapters "Mouse routines", "Keyboard routines" and "Joystick routines".

3.2. Processing: More often than not you can do this step with no Allegro functions whatsoever. In fact I think you shouldn't use any at all here. All you need for processing are the programming constructs built into the languages of C and C++. Very often you will also use the part of the standard C library that you get access to by including "math.h". You should especially avoid using Allegro functions that deal with graphics in this step (getpixel is one such function you should not use). Note: You should probably ignore the chapters from the end of the Allegro manual that deal with math.

3.3. Output: This will be the beefy part of the game. Here you will use the most powerfull parts of Allegro: "Drawing primitives", "Blitting and sprites", "Text output", "Polygon rendering", "Transparency and patterned drawing", "Digital sample routines" and "Music routines (MIDI)". You will draw your game world to the screen and play samples and music. You will not do any input gathering or processing here.

4. Cleaning up: Here you just free all memory and exit.

Once you implement your game in this way, you will have a solid system that will work the first time and you can easily add to and build upon as you learn new tricks.


Wow that simplifies a lot, I bought Game Programming All In One which covers c++ and Allegro and they don't explain a lot of their code so asking questions and reading online articles is how I smooth out the cracks. Thanks for taking the time to respond to my messages, all of you.

Thread #587804. Printed from