In an attempt to speed up the fine scrolling on small map sections in my engine, I decided that instead of cycling through the array of tiles and blitting each one at a time onto a back buffer, then blitting that to the primary surface for each frame, that I would blit the entire map(about 108x78 tiles) to a surface, then to draw each frame I''d simply position a rect the size of the display on the appropriate part of the large surface and blit that to the primary surface. My estimations for the number of blits that are required for each method are: ~600 or so small blits for method one per frame, and 1 large blit per frame plus ~8500 at startup to blit every tile to the large surface. My plan was to sacrifice a bit of start-up speed and memory for a large increase in frame rate. Instead, the frame rate has been approximately halved. Maybe my idea is flawed from the start, but can anyone think of a reason why?

Maybe the entire map for method 2 wont fit into video memory, so it is using system blits instead.

I considered that, but actually all my surfaces except the primary are in system memory because my vid card doesn't have enough memory to hold the primary, the back, and the tile surfaces so I moved the tile surface and the back surface to system memory to speed up the blits onto it.. I realize how slow that is, but I'm doing that in both methods so I thought there would be at least some speed increase because of the drastic cut in locks/unlocks.

Edited by - Effigy on 2/23/00 12:06:50 AM

I believe it has to do with memory caching. The large surface doesn''t fit in the cache and must be swapped every once in a while, in worst cases once per scanline.

The small tiles all fit in the cache one at a time and doesn''t have to be swapped during blitting, which makes it a lot faster.