Let me begin by explaining how my map drawing currently works. First, there is a tile_layer BITMAP that is slightly larger than the 'screen'. Currently, there is 64 pixels bounding space on all sides. Each frame, tile_layer is blitted onto the frame_buffer, followed by any other sprites that need blitting. Make sense so far? Good, cuz this is where it gets complicated.

Whenever the screen view goes beyond what is contained within the tile_layer, it is repositioned and redrawn. This means the tile_layer is only redrawn ever few frame while the screen is moving, at not at all while it's not moving (I thought this was a good idea, at least). Here is the function that handles that (most functions are self-explanatory; if you don't understand what something does, just ask.):

And the function call to tile_layer_redraw() is as follows:

**NOTE: MAP is an array of tile objects.

and add_tile(...) is just a shortcut for blitting to the correct surface. The idea was to make it shorter, simpler, and less error prone.

// draws a tile to tile_layer, at the given coordinates.
void CEngine::add_tile(BITMAP *tile, int x, int y)
{
  blit(tile, tile_layer, 0, 0, x, y, tile_size, tile_size);
}

Now, for the problem...It's still slow. It's much, much faster than redrawing all of the tiles each frame, sure, but if the screen is scrolling till it reaches the edge of the tile_layer (time to redraw), you can notice the shift...it's rather jerky looking, and overall I think it uses too much CPU (but this is kind of hard to check). Does anyone have any suggestions on how to improve this?

I would also appreciate if anyone who tests this would tell me how well it ran for them, and on what OS. Since I've changed to page-flipping, someone reported to me saying it no longer runs on Linux (it segfaults).

*source is included if your either interested in "borring" my work (which is fine by me, but I dont know why you would want to), or for reference. Sorry about it being so sloppy, but the project is only for testing purposes. I will rewrite it once I figure out how to get the thing running as fast as I possibly can.

Yes, it would seem logical to NOT draw bitmap A to bitmap B, then bitmap B to screen, but theres a reason for it. Based on experimentation, it's much faster to draw one large bitmap than many small ones. What I'm saying is, the reason for the tile_layer is to avoid having to redraw each tile each frame. This method is very slow.

I tried running this code:

Crude, but an effective test. It ran at about half the FPS of the tile_layer method.

As for my function to redraw the tile_layer...well, it is difficult to explain, but in short the first part (the ifs and if-elses) just repositions the tile_layer. Both the "screen" and tile_layer are based off world coordinates (their x and y positions from 0, 0: The top left of the map). No need to worry about that part, as it works right. The highlight was that it only actually will call the redraw_tile_layer() if the screen goes out of bounds of the tile_layer.

Could that perhaps be because you are failing to acquire/release your video memory bitmaps?

Modern operating systems like to run all the various programs in separate memory spaces so that any crashes don't bring everything down. However, video memory is a global resource. The act of acquiring a video memory bitmap gives your process access to the global resource. This is probably exclusive access, so you should release your bitmap so that other processes can make use of the video memory. In windows you should release because you won't get any user input while the front buffer is acquired.

Acquiring and releasing is a slow operation. If you attempt to draw to a bitmap that requires acquiring/releasing and you have not done so then Allegro must.

Hence, if you had a loop like the one you just posted but frame_buffer was in video memory (e.g. if it was "screen") then every time you call draw_rle_sprite Allegro has to acquire and then release the bitmap. If you add "acquire_bitmap(bmpname)" before your loop and "release_bitmap(bmpname)" afterwards then Allegro does not need to acquire within draw_rle_sprite because the bitmap is already acquired.

If you aren't modifying your bitmaps much except by blitting from other bitmaps, have you looked into just using video bitmaps for everything? On 99.9% of Windows machines that would give a gigantic speed boost by taking work off the CPU. Just make sure you include a fallback for OSs where Allegro doesn't use the hardware.

Certainly the Mac OS X port of Allegro doesn't. The Linux port may not depending what video system it is relying on. Similarly the Windows port may not if the graphics card doesn't. That's a rare thing nowadays but if you want to write rock solid code you should allow for the possibility.