[EMAIL PROTECTED] makes some magical things to make me read } } > Not "some" programs, but the specification of the graphic format: } > original QL mode (4/8) must be rounded on word } > new GD2 mode (even the 1 bit per pixel: B&W) must be rounded on long. } } I do not see why we should insist on them being rounded on longwords - surely } you are not suggesting that even for monochrome mode (1 bit per pixel) or } Aurora's 8 bit mode (1 byte per pixel), we should actually store 4 bytes for } every pixel !! } } This is one of the standards which we need to agree on... } } Surely for monochrome or 8 bit graphics, we can simply keep the line length } rounded to the next byte...
I'm sorry, but I really believe in the SPEC (even when bogus). There is time where I would like to change the spec too, but I have to obey it anyway as long as it is not blatlantly in error with the previous/real implementation [most significant byte of sprite mode for QL is 1, and 2 for GD2, not 0 and 1]). Your only hope is a reverse enginering of the current monochrome drivers to demonstrate that previously alignement was on byte boundary (which I currently ignore). But so far, you will have to live with the words of the GD2-spec (Holy bible ?). For sprite (mask&pattern), even for 1 bit black & white, all lines must be aligned on long (exact reference: GD2-User.doc, page 8, "Each row in a QL mode pattern or blob occupies one or more and complete 16 bit words. Each row in any extended colour definition pattern or blob occupies one or more complete long words.", just one paragraph after the table which list the new GD2 mode). I'm just extending that requirement in the PIC format which is similarly based (in fact PIC format already inherited such extension in the current implementation of the PE routine for saving/restoring an area. Just that so far, the only code that I know only handle 16 bits pixels, so aligning on long is only one pixel waste at worst [and occurs rarely, because most of the time the size is even!]) } } > } > The only bad thing about the PIC format is that you cannot easily } > ask to ignore the pixel on the left part: the first pixel of the line } > is always used. It's only a burden for screen-catcher as either: } > - they force to round the left origin ( by 8 for a mode 4 for instance, } > things are easier with high-colour GD2 mode) } > - they have to perform some shifting themself before saving the area } > into the file. } > } } I am not sure what you mean here - as far as I understood, if you save an } area 4 pixels wide (in mode 8 for example), the PIC file only uses 2 bytes to } store those pixels, wherever the origin of the area is on the screen. It is } up to the storage routine to ensure that the first pixel in the PIC file is } the first pixel required on the screen, and similarly for the display } routine. Exactly. It's nearly ok with 16 bits drivers, but it was a real torment with original QL modes 4 and 8. And it would be too with any reduced colour mode. (at least, no mode are specified so far as to use 3, 5 or 7 bits per pixels without padding at the byte level) } } I am working on a m/c toolkit to store and display PIC files under any modes, } any offers to assist me with this... or maybe someone has already written } most of the code somewhere.... Na... forcing me to disclose some advancement... There is in its way a code to display cursor/sprite/mask/pattern from any mode (upto a size of 512x256) on 16 bits hardware display. Any mode include the whole set of GD2:0,4,7,8,15,16,31,32,33 and 64 as well as old mode 4 and mode 8. May be you could reuse the conversion routine (it should be really easy to do so if I can explain you the structure expected by the code [you shouldn't be restricted by the 512x256 limit if you allocate the needed memory yourself, and this will provide you with the needed reentrancy]) PS: And if you ask, the alignement of the data is currently done at the long boundary for all the GD2 mode. -- Grimbert J�r�me
