Mail Archives: djgpp/1997/01/26/20:27:04
>>*Map[100][75] ) and I later declare Map[x][y] = create_bitmap(40,40) ...
>>well thats a lot of memory used but I thought it would save on speed
>>later, BUT I still have slow downs!! If anybody can help on this, I
>
>Try using compiled bitmaps or RLE bitmaps. They are MUCH faster than the normal
>Allegro bitmap. There are other sources of speed loss, of course, but the
>bitmap type is an immediate concern.
Compiled and RLE sprites only help if you are drawing masked sprites
(with cutout areas formed from color zero), because RLE sprites reduce
the number of tests required, and compiled sprites eliminate the testing
altogether. If you are drawing a solid background (which I assume is the
case in a tiling engine), you should be using blit() rather than
draw_sprite(), and the blit routines don't bother testing for zero
pixels in the first place.
I'd be a bit concerned about the amount of memory you are using, though!
If I'm working it out right, that map is using around 11.5 meg just for
the pixel data, quite apart from the bitmap size information! On an 8
meg machine that's going cause a lot of disk thrashing, and even with 16
megs it's going to be tight (and will do bad things to your cache :-)
Are there no duplicate tiles that can share a single bitmap?
Regarding your speed problems, there are various things I can suggest,
but remember that depending on your system it may not be possible to get
a really good framerate - a 640x480 screen is a lot of pixels to draw.
Are you currently drawing to a memory bitmap, or straight to the screen?
If you are using a memory bitmap, it may be worth using two buffers in
video memory and page flipping between them (see examples/ex9 for a demo
of how this works).
Another significant factor is that blitting is much faster if the
destination x position is a multiple of four. If you want smooth pixel
scrolling there isn't much you can do to ensure this is the case, but
it's worth bearing in mind. If the screen only scrolls when the player
gets near the edge of it, maybe you could make it quickly scroll 8 or 16
pixels, and then stop again on a multiple of four, so most of the time
your tiles are well aligned. Or you could draw all your tiles in aligned
positions, and then use mode-X hardware scrolling to get the exact pixel
location you want (unfortunately that won't work in SVGA because a lot
of cards can only hardware scroll in four pixel increments).
If you try all that and it's still too slow, the only solution is to
reduce the amount of data you are drawing each frame. If anything stays
the same from one frame to the next, don't redraw it (this can get very
complicated with scrolling engines, but that just makes it more fun :-)
/*
* Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
* Ghoti: 'gh' as in 'enough', 'o' as in 'women', and 'ti' as in 'nation'.
*/
- Raw text -