On Sun, Mar 09, 2003 at 09:16:02PM +0100, Laurens M. Fridael wrote: > So in effect Adam's solution has the limitation that images can only be 30K > pixels wide in the most extreme case(with 16bpp). That's about 9 screens > across on a high-res device. Images this wide will lead to gigantic PDBs, so > in practice you won't even go near this limit. Anyway, you're calling the > shots here.
I agree with Mike when he says that I'd be replacing one limitation with another. It may be best off to just split the image up into squares. How about this.. pieces = tbmp size / max memory + 1 (same as before) pieces += pieces % 2 (to make sure we have an even number) The parser then picks some arbitrary values to define the rows and columns. This is pretty much up in the air just as long as the two values multiply together to equal the number of pieces. For example, we find we need 6 pieces, and the parser decides 3 columns and 2 rows. Our image now looks like this: w1 w2 w3 ____________________ : : : : : : : : h1 : : : : -------------------- : : : : : : : : h2 : : : : :_____:_____:______: w1 = w / columns w2 = w / columns w3 = w / columns + w % columns h1 = h / rows h2 = h / rows + h % rows Ofcourse, DATATYPE_MULTIRECORD would require a header at this point. Lets say.. Columns .. 2 bytes .. Numeric .. Total number of vertical crosssections Rows .. 2 bytes .. Numeric .. Total number of horizontal crossections Then finally a list of 2 byte uids to the actual images, in linear order from left to right, top to bottom. When the viewer attemps to draw the image, it will know how many columns/rows/pieces are involved and can place each individual image in the proper location accordingly. Can this work as a better solution? On Sun, Mar 09, 2003 at 06:17:29PM +0000, Michael Nordstr�m wrote: > Anyway, your current suggestion will not be used, but don't throw > away the code. Maybe some part of it can be used for a solution that > can handle images that have been split in both directions (maybe you > would even be interested in implementing such a solution?) Still, it > might be a good idea to wait until we know what would be possible to > create in the parser... Well, I guess the reason why I'm spearheading this is becuase I want to get it implemented and out of the way :) I know that plucker itself isn't an image viewer by nature, but could easy be used as one. This is mostly a problem on hires devices becuase of the larger space to draw images.. it would be nice to actually have images that fully utilized the drawing area with the highest bitdepth possible. -- Adam McDaniel Array.org Calgary, AB, Canada _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
