[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Bit-Depth and Graphics stuff....


8 jul 2010 kl. 22.30 skrev Michael Bernstein:

Hi,

You are right if you point out, that this way consumes some CPU power.
But it is the clean way and will work with every hardware.

1. Straight conversions from source->device dependent format is ok in true color.
2. Straight conversions from source-> device dependent format in palette modes is a no no?

Come on.  Doing a straight conversion -> device dependent planar graphics has 0 (as in zero, null, nill) impact on compatbility if you have a fallback rout. That fallback routine would be the VDI transformation function.

The only thing that happens is that people with (accellerated) standard machines get better performance. And this is actually a problem in many cases; even if you're on a 060-equipped falcon. It's so easy to do all this, it doesn't break compatibility, and it affects performance a *lot* on machines with standard graphics (read: Falcon CT60).

That this somehow should be "proper" in true color and a bad idea in palette modes is just not true. It's the exact same procedure even though the algorithm is slightly different.

The result of vq_extnd will show, if you have palette mode (work_out[5])
and the color depth (work_out[4]).

For palette mode with up to 256 colors you should always let the VDI do
the work. Because you dont have informations about the organization of
the video ram, you should allways use the device independant format
and let the VDI transform this bitmap with vr_trnfm to the device
dependant format before copy it to the screen with vr?_cpyfm.

Incorrect. You know just as much about the pixel format as you do in true color modes.

This will
allways work on all GEM machines. This is one of the golden rules of
portable GEM application: dont make assumptions about the system. And
this includes also the organization of the graphics card.

The true color case is about assumptions, because the only way to know the pixel format for sure is to probe the screen. That's not the case in palette modes.

You guys got this backwards.

-- PeP