To use dirty rectangles in your small program instead of double buffering:

1. Simply save the part of the screen that your box is going to be blitted to (using blit())

2. Blit() your image box or whatever you have to its destination on screen.

3. Calculate the new position from keyboard input or whatever...

4. Blit() the original part of the screen from step 1 back to its place.

5. Start over at step 1 with a new (x,y)

Thank you for your reply, but I don't really understand.:-/??? Like I said: I'm new to coding with C and allegro... Perhaps you have an old (small) code which includes Dirty Rectangles.
Sorry, if my questions sound stupid, i'm not good in my English-classes either.:-[

Sorry that AGDN tutorial only confused me further when trying to learn all about DRS. The tutorial was wrong IIRC because it used a sort of DRS, but still completely double buffered the screen... but it could also help you understand the problem. My way was sort of both Mirans and the other guys way (sorry about that).

1. Create buffer exactly as you would using a double buffer.
2. Create a seperate buffer the size of teh image you wish to make a dirty rectangle out of that will hold the background information of the buffer so when it moves you can erase where it was.
3. Copy the buffer into your seperate buffer where the sprite will be.
4. Blit your sprite to the buffer
5. Add a dirty rectangle to the list (simply a linked list containing x, y, w, and h of your sprite)
6. You may wish to make the DRS "smarter" by combining rectangles or deleting those that exist inside another rectangle.
7. Blit your dirty list to the screen from the buffer.
8. Blit your seperate buffer to the buffer to erase what you just drew
9. Move sprite
10. Repeat 2 - 10 until program exits.

Sounds complicated but generally isn't. Good Luck.

It depends on what you're doing. If you have lots of rects and many overlap you can save quite a bit of time but if overlapping rects are few and far between then most of the time the code will just iterate through the list for no reason doing a lot of unnecessary checking ultimately proving to be more trouble than it's worth. The only way to answer the question is to implement the algo and make some tests...

With all that in mind it has to be said that with the processing power of todays CPUs the performance lost or gained will most probably be minimal...

Before implementing a dr algo, be sure you are making the right kind of game for it. As soon as you have scrolling backgrounds, parallax effects, or do 3d, or for some other reason update most part of the screen in every frame, double-buffering is the way to go (or check if triple-buffering is an option).
If you only need to update small areas though, dirty rectangles is for you.
Anyway, 60 fps is about as fast as you need; the eye won't really notice the difference anyway. In fact, in a 60Hz screen mode, the image quality will suffer from any update rate above 60 Hz, because the image will be updated mid-frame.
/// EDIT ///
Re-reading the above posts, it seems that there are two opinions on what DR actually means.

Method 1:
- Create a back buffer like double buffering
- For each object that moves, mark source and dest rects as dirty
- Redraw back buffer (could restrict this roughly to dirty rects, ie redraw only objects that intersect with dirty rects)
- Blit dirty rectangles from backbuffer to screen

Method 2:
- For each object, create a backbuffer the size of the object
- Before drawing the object, save the previous screen contents to the objects backbuffer
- When moving, restore screen content from backbuffer, then save from new position, then draw.

While method 2 is certainly faster and needs less memory, it has the big disadvantage that it only works correctly if either first all sprites restore, then all sprites draw in the exact same order (but that can easily cause flicker), or if no two sprites overlap. This might be feasible for some kinds of games (tile-based come to mind), but not for others (side-scrollers).
I would go for method 1 even if not necessary, because if you do your drawing somewhat cleverly, there shouldn't be too much speed difference. And you can do whatver you want with your sprites.

Toggle the button on the lower right hand corner of your monitor

Ok, bad joke - you can't disable the retrace, but you can choose not to wait for the sync, however this is generally a bad idea IMO. Image quality will suffer and you will/may get flickering. (See Tobias's post above)