From mint-bounce@lists.fishpool.fi Sun Jul 11 23:28:52 2010 Date: Sun, 11 Jul 2010 11:46:30 +0200 To: MiNT Mailingliste Subject: Re: [MiNT] Bit-Depth and Graphics stuff.... Message-ID: <20100711114630.B16224@mbernstein.de> References: <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> <47B6FCDC-13AA-4B15-BF8B-2A59E6E9991F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <47B6FCDC-13AA-4B15-BF8B-2A59E6E9991F@gmail.com>; from pep.fishmoose@gmail.com on Fri, Jul 09, 2010 at 09:52:01AM +0200 From: "Michael Bernstein" X-Df-Sender: 731418 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mint@mbernstein.de Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Hi Peter, > 1. Straight conversions from source->device dependent format is ok > in true color. No, it is not ok because you have to break one guideline rule of GEM programming. But there is no other choice because the VDI lacks the support for true color mode. There is no definition for a device independant format which let you work with vr_trnfm like in palette mode > 2. Straight conversions from source-> device dependent format in > palette modes is a no no? Yes it is not ok because you have to use informations got by probe the target instead of use defined knowledge and inquire functions. So your code based on assumptions. It will work because you probe it but break one rule of GEM programing. > 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. After such long time i thought people had learned to use the operating system instead of work around the OS because of no side effects and extra speed. And many of the no side affect solutions failed with the next generation of Atari computers. GEM show you the way by defining a device independant format an a function to convert beween both formats. It is always a bad idea to work around GEM because someone think his solution has no side effects, does not break compatibility and have extra benefist like more speed... There are only a few exceptiosn from this rule. One is the true color format because there is no definition which allows it ti handle such bitmaps with the raster functions. > > 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. No, it is correct. There is no definition about the device dependant format and no inquire function present in all vdi versions which give you informations about the organization of the device dependat format. The way given by GEM is the use of vr_trnfm. Yes, you can probe it like in true color mode. But if you have to probe it, it means you dont have this information. Otherwise it is not neccessary to probe it. > The true color case is about assumptions, because .. Thats what i wrote. Best regards Michael Bernstein