On Wed, 07 Jul 2010 20:12:46 +0200, m0n0 wrote: > I had a quick look into several ports (windows, amiga, framebuffer) and > looked for the bitmap drawing routine. It seems every port needs to define > it's own bitmap structure, is that correct?
Yes, it is. You need to keep hold of the width, height and pixel data at a minimum. The implementation is up to you, but you do need a storage area that the core can write into as it supplies raw pixel data (it won't write directly to a custom structure or provide the data line-by-line/pixel-by-pixel to be piped into another structure) > The Amiga Bitmap structure > looks completely different than the window bitmap struct. Manipulating raw pixel data isn't as easy or fast as manipulating an Amiga BitMap, and old-style scaling functions are slow, so the extra fields are there to make things a little quicker. > Is it correct that the bitmap drawing method of the plotter gets fed with > different pixeldepth and formats? Depending on the native Bitmap that was > downloaded? Or is it an generic format that eventually needs to be sampled > to an lower amount of colors (depending on the native resolution)? It's in 32-bit RGBA format on big endian hardware, you shouldn't get anything else. You can return a lower value for bitmap_get_bpp() but I've not seen the point or any advantage to doing this. The plotter code then needs to print that on the screen, taking care of scaling, tiling and downsampling. I have an intermediary step which optionally caches the native scaled BitMap to speed up future plots, you could do something similar to cache a dithered downsampled one to speed up page redraws (I don't bother with downsampling here, the OS handles it automatically although it doesn't seem to bother on <16-bit screenmodes, so I should perhaps add it at some point - it's likely to be about two lines of code) Chris
