From mint-bounce@lists.fishpool.fi Fri Jul 9 03:56:56 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=p9nRssXDB0SNBp60ERQxWIcMyuL7CSagzKfFM1AswB0=; b=X1OUml3k6t6L8p1sAIG0pzgXdVxr7ASxLrQ67vS/JoDHn93q9RN7UXAJ+35tH21dum m2f/0APnm9u3xW8z1t3dRDD+br0ayvs2R8xrSLeEsV7jN96+NCtaaAZhAI1cC+A7zDXC 6v67lhmaG/8e1aAFeG5lA5icz4GyfWWqsf2/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=s2VhgSjN8EbjB/uT8utvPl/QJPbvPJgVuhZLQ+TRQLVCKRec5Y4aXV3hoHh74t2E6s lLKlBs3yNEyQz6PXpgELH0sDNojBg0A05gJvLQ1TRVUrtg0vLHHWJHdMqpnoDWbMS2Cy NN/pnxgy2Qm9L3rRL0AId1Mb3KhrAoCr+LTUk= Subject: Re: [MiNT] Bit-Depth and Graphics stuff.... Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-10--292988862 From: Peter Persson In-Reply-To: <20100708223029.A20680@mbernstein.de> Date: Fri, 9 Jul 2010 09:52:01 +0200 Cc: MiNT Mailingliste Message-Id: <47B6FCDC-13AA-4B15-BF8B-2A59E6E9991F@gmail.com> References: <2d64e795294918b05c6ec6ea3bc731b7-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUBFBDBTXF5bVkYPXkF0A1Y6XF1YSUYAWVNeQw==-webmailer2@server08.webmailer.hosteurope.de> <6BF9B6DD-38A2-4874-8D8C-10EE1E99E6DD@gmail.com> <1BCB0F08-DCCB-423A-B4E1-CCDB279C6B83@gmail.com> <6dbce3cf64caf9c3441739836652cad8-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUBFBDBTXF5bVkYMXUF0BVM6XF1YSUADWl9cQw==-webmailer2@server05.webmailer.hosteurope.de> <4C34C2E4.5080909@online.no> <3847624A-0252-410C-B103-5BA7AAE195E0@gmail.com> <20100708223029.A20680@mbernstein.de> To: Michael Bernstein X-Mailer: Apple Mail (2.1081) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: pep.fishmoose@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: --Apple-Mail-10--292988862 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 8 jul 2010 kl. 22.30 skrev Michael Bernstein: > Hi, >=20 > 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]). >=20 > 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 --Apple-Mail-10--292988862 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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

= --Apple-Mail-10--292988862--