Mail Archives: djgpp/1999/09/03/19:52:50
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.
- Raw text -