set_color_depth(32);
    if (set_gfx_mode(GFX_AUTODETECT_FULLSCREEN,1024,768,0,0)!=0) {

There's the cause of your slowdowns right there. Switching to 16-bit colour will almost double the framerate. Switching to 8-bit if you can will double it again. (Provided you don't make too many calls to makecol().)

Also, 1024x768 is a very high resolution to be doing non-accelerated doubled-buffered graphics at. It may only be 2D, but if it's the CPU that has to handle the drawing then an over 2 GHz difference in processor speed is going to have a big effect on gameplay.

If you've ever played Mechwarrior II back in the days of DOS you would know that it had a 1024x768 mode. Even on a 600 Mhz computer I once tried that on it only ran at a framerate of about 8.

Without hardware acceleration you need to be careful how much data you're trying to push at any one time. 32-bit colour, 1024x768, and double buffered graphics all together are going to kill the framerate on older computers.

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

Dog?
That's better than both my laptops and my brother's laptop put together. Two of my computers are worse, as well...

A dirty rectangle system only updates rects on the screen that have changed since the last update. So, instead of updating the complete screen, you'd only update small parts of it.

I doubt it. Unless they are extremely large bullets, or there are hundreds of them, you'll still benifit hugely by using dirty rectangles. Suppose you've got 20 bullets each of size 32x32: 32x32*20 / 1024x768 = 3% of the screen.

However there are few things more boring than a game with a static non-scrolling background.

There are different types of Dirty Rectangle Systems, the Allegro demo uses one as an option too. I think I even posted a simple one on this forums some years ago. Do a search on these forums and I'm sure you'll find plenty of info..

Of course, optimizing these areas (merging to reduce overdraw / function calls) etc is non-trivial, but also not really vital (profile!)

The simplest way to implement dirty rectangles for your game would probably be:

1. Eliminate the buffer. Do all drawing directly to the screen. (This will mean that all drawing to the screen has to be done at once between an acquire_screen() and release_screen() pair unless you store everything into video bitmaps. (Which would be faster but has an added complication of having to restore all video bitmaps if there's a task switch.))

2. All sprites must store their previous positions from the last frame. This is because you only ever redraw sprites which have moved. (Or animated.)

3. You never clear the screen. You simply clear any area you're about to draw to. (IE: If you're about to draw a paddle in a new position, you blit the section of the background the paddle was previously over to the screen, then blit the new position of the paddle immediately afterwards.)

For instance, for drawing any sprite you would have the following mock code:

blit(bg_bitmap,screen,sprite.prev_x,sprite.prev_y,sprite.prev_x,sprite.prev_y,sprite.h,sprite.w);
draw_sprite(screen,sprite.bitmap,sprite.x,sprite.y);

You could probably convert that into a special function to make such drawing simpler.

The buffer is the big performance hit with the screen resolution and colour depth you're using. Eliminating it eliminates not one but TWO full-screen blits every frame. That's a lot of CPU power you're getting back!

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

Ok, we simplify.

You have double buffer
double buffer good.
blitting all of buffer every frame not good
blitting only needed part of buffer good

keeping list of changed regions helps
blitting only changed regions will make game fast
fast good

Nah, but seriously: All you do is instead of blitting the complete buffer, you only blit changed parts of the buffer. Since this will be even faster than blitting the complete buffer, you get all benefits without drawbacks.

If you don't want to keep a list, try this (it's not quite as good, but should be easy to implement):

Your screen is 1024x768
Divide that into quads of 128x128

Whenever you draw something mark the quad you're drawing in as "dirty".
When you blit the buffer, only blit the "dirty" quads.
If more than "n" quads are dirty, blit the whole screen.

This way you can keep a simple array to keep track of the dirty parts.

Another option:
If the only things moving are:
The paddles, the ball and the shots, you can blit the paddle columns, the area surrounding the ball and parts of the line of each shot.
The area you need to blit can be easily found by the speed of the shot / ball and it's current position.
Then you don't even need to mark the area as dirty, you can simply calculate what#s dirty.

Because both the backbuffer and the screen will only be updated as needed.
Right now he creates the backbuffer every frame (by blitting the bg image, then the sprites) and blits the result to screen.

with the DRS he'll be updating only what's needed.

For some reason your explanation made me blissfully more aware. I just fear that it could get complicated with the logo and scores (just use ifs to determine if a part I need to redraw lies in one of those areas, right?). Anyway, I did figure out how to dirty rectangle the paddles (as long as it's acceptable practice that it redraws the whole column, not just around where the paddle actually is).

I don't need to track the previous positions of the objects (at least, I don't think I need to). Everything except the ball moves at a constant rate (and the ball has variables to track its speed), so I can just calculate the previous position.

Yep. And blitting the fullscreen bgImage to the backbuffer is the 2nd. (Well, actually it's the first, and bliting the backbuffer is the 2nd).