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

[Paul Wratt <paul.wratt@gmail.com>]

On Fri, Jul 9, 2010 at 5:52 PM, Peter Persson <pep.fishmoose@gmail.com> wrote:
>
> 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
>
OK, so what exactly is your suggestion here. There is a need for an
API that works on all platforms, no matter what the hardware makeup
is, and portable in some way, preferably with a hefty boost in the
speed department too

Paul