From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: Allegro: Tile base scrolling in 640x480 with 256 colors Date: Sun, 26 Jan 1997 22:42:46 +0000 Organization: None Distribution: world Message-ID: References: <32E87F30 DOT 1C74 AT ix DOT netcom DOT com> <32e8c430 DOT 2195404 AT ursa DOT smsu DOT edu> NNTP-Posting-Host: talula.demon.co.uk MIME-Version: 1.0 Lines: 52 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp >>*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'. */