Mail Archives: djgpp/1999/09/04/14:45:04
Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk> wrote in message
news:8D53104ECD0CD211AF4000A0C9D60AE3016164A2 AT probe-2 DOT acclaim-euro DOT net...
> nightwalker writes:
> > I want to make it working at 800x600x32bit color, double or triple
> > paging (they seems the most reliable methods).
Restricting your audience to those with 32 bit color at such
a high resolution, IMHO, is generally a Bad Thing. If I were
you, I would make this Warcraft-style strategy game run at
512x384x8, 640x480x8, 800x600x8, and 1024x768x8.
Eight bits will give you the best frame rate on any hardware.
Many laptop computers (including mine) can only display
natively at 512 and 1024 res; they scale the image in real
time to 640 and 800; Blizzard's Starcraft begins to look
like crap.
> 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.
Like Shawn said: Use the grabber to put RLE sprites
into a datafile. If you are storing bitmaps any other way,
you can convert them at runtime with get_rle_sprite().
> > 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.
However, if you want to get started on redrawing the graphics,
it may be a good idea to make your game using the "Web safe
palette," "6x6x6 color cube," "Macintosh default palette," or
some other name for the uniform palette. BTW, this palette is
in DOSArena. Dowload DArena1b.zip, unzip it, run grabber on
DOSArena.dat, and pull out PCPAL into a bitmap file. Use this
file's palette in everything you convert, and it'll look halfway
decent. It's up to you and your paint program to make it look all
the way decent.
Damian Yerrick
http://come.to/yerrick
> > 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 -