Hello,
I would like to know things (other that I found out so far) that need to be inspected when tuning allegro application (game), for performance, in my case it is 2d game where lot of objects can be shown on screen.

The performance isn't really bad, but I would expect that drawing 2d scene with approximately 2500 images (mostly tiles and some objects) on high end computer should be faster than 500 fps that I have now.
I really don't need 500 fps, but I expect number of shown objects to increase a lot and I also want to be able to run the game on much less powerful computers, my friend on laptop has only 150 fps now.

Here is the list of things I already discovered/checked:

1) al_hold_bitmap_drawing before(true); before drawing lot of bitmaps and al_hold_bitmap_drawing before(false); when I'm finished (helped a lot)

2) This needs to be tested more, but When I draw 100 X 10 different bitmaps it is much slower than drawing 1000 X 1 bitmap.
Is it because of some switching of source bitmap for drawing?
I guess that it might be solved using some atlas bitmap for all images I use and just drawing part of the bitmap, but it is limited by the maximum size of the atlas bitmap that can be in video memory.

3) I checked that bitmaps I use for drawing are video bitmaps.

4) I discovered, that when I only flip display, the fps is 1800, I always thought that flipping backbuffer should be practically instant, could it be because I have some bad backbuffer settings?

Have you done any profiling?

IMO it's better to worry about this when performance becomes an actual issue.

This helps a lot more if your bitmaps are merged into a single bitmap. You can make the individual bitmaps subbitmaps if that makes it easier. It's called Atlasing, and it makes it so the 3D api that allegro uses, doesn't have to change textures, which is a fairly slow operation.

Check if you have NPOT (Non Power Of Two) texture support. If you don't doing odd things like this will create much larger textures than you ask for, wasting a lot of memory.

I've heard (but don't know if its true) that D3D will batch up rendering calls, and then actually execute them on Flip. I really don't know if that's accurate, but it could explain why a flip is slower than you'd expect.

Thomas Fjellstrom: Thank you for the reply.

If I wanted to use the atlas method, is there limitation of the atlas bitmap size?

Yes, the GPU has a max texture size you'll need to check for. It can vary, modern cards support at least 4096x4096, with many support larger (8192 or 16384 possibly) textures. Older cards may only support 2048 or less.

As a note, my laptop which is a few years old now, and uses an integrated Intel GM45 (4500MHD) gpu, supports a max texture size of 8192x8192.

append:

Here's how I checked (because I couldn't quickly find an easier way):

#include <stdio.h>
#include <allegro5/allegro5.h>

int main(int argc, char **argv)
{
   ALLEGRO_DISPLAY *dpy = NULL;
   int maxsize = 0;
   al_init();
   dpy = al_create_display(640, 480);
   maxsize = al_get_display_option(dpy, ALLEGRO_MAX_BITMAP_SIZE);
   printf("max texture size: %ix%i\n", maxsize);
   al_destroy_display(dpy);
   return 0;
}

Thank you for the info and the example, that will be handy.

8192x8192 is sufficient atlas to hold all the (even animated) sprites that I can imagine to need

Very likely, but don't assume because his card supports such a huge texture size, other cards will.

As far as I know, only very few cards support such large textures, some even only support up to 1024x1024.

If you want to support really old hardware, or really crappy hardware. Even my 4500MHD (GM45) integrated Intel video has 8192x8192. The laptop itself is 3 years old or more, and the video chipset is older still. If my laptop can do it, so can the majority of semi modern computers.

But, its still best to check for texture size, and if needed, split your resources into multiple atlas's.