Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE3016164A2@probe-2.acclaim-euro.net> From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: ALLEGRO RLE_SPRITE direct initialization Date: Fri, 3 Sep 1999 16:18:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Reply-To: djgpp AT delorie DOT com nightwalker writes: > I want to make it working at 800x600x32bit color, double or triple > paging (they seems the most reliable methods). You mean flipping between two different areas of video memory? That is often the fastest way, but may not work on all hardware. Double buffering using a temporary area in system memory is far more reliable, and can be faster on some machines as well. The best thing is to implement all three methods, and let your users choose whichever works best on their machine. Allegro is designed to make this easy to do. > I use lots of images (units' frames) with the same size (48x48) and > color depth (32bit), so I would store them in a different file format > than a DAT containing PCX or BMP. I would recommend using an Allegro datafile for this: it is exactly the situation that they were invented to deal with. Datafiles contain Allegro format data (in your case it would be RLE encoded sprite images) rather than actual copies of the PCX or BMP format: it just imports from those file formats to get the data into the grabber program. > How can I initialize the RLE_SPRITE.dat pointers on my own? Look at the library sources if you need to see details of how the RLE encoding works, but I wouldn't recommend messing with this yourself: if you don't want to use the Allegro datafile system, load the data into a conventional bitmap and then use get_rle_sprite() to compress it. > Is possible a run-time conversion from 32 bit color to 24, 16 and 8 bit > depth? The blit() function will do this for you (not with RLE sprites, though: you need to be using regular bitmaps if you want to do anything more complicated than just drawing them to the screen). Or Allegro can automatically convert all your graphics while loading a datafile: look up the set_color_conversion() function in the docs. Reducing truecolor source graphics to 8 bit isn't really very useful, though: it is extremely slow, and the results will look terrible. You need some manual involvement (along the lines of redrawing lots of the graphics) to make this sort of extreme color reduction come out looking good, so it isn't something I think you should try to automate. > About video buffering: I cannot see the advantages of triple buffering > vs. double buffering. If your hardware can already run the game at full framerate, there is no benefit. The gain is in the ability to deal with fractional frame counts, since triple buffering allows it to get on with drawing the next frame even while it is still waiting for the video card to finish flipping to display a previous one. This can make things much smoother if your redraw times are very uneven, or if your code update speed is stuck in the gap between two even ratios of the monitor refresh, eg. so that your game can draw at an average 50 fps on a 70 fps display, rather than getting rounded down to 35 fps. Shawn Hargreaves.