[EMAIL PROTECTED] makes some magical things to make me read } Whilst on this subject, it seems very hard to write a PIC file viewer which } can handle all of the different display modes. } } 1) What is the best way of detecting whether GD2 drivers are present and in } use??
If you can wait a little, I should write a new trap soon (as I said, the code is on its way, which means its not yet finished, even if the low-level system part is running now ok over my hardware) which will take care of that via the system. It will convert a collection of rows into another collection of row in native mode (if the original mode is supported: I'm still wondering if it is worth for the QL mode4/mode8 driver to be able to use GD2 sprite ?) (It's a bit more complicated than just a collection of row, but that's the spirit: you let the system do it for you, then you can just write it as any pattern) I really believe that the various GD2 modes should not be a burden for an application programmer, but an opportunity to choose the best suitable format for the data. Therefore, the usage of GD2 drivers should not add any code (such as which mode is running) into the application. You may want to use the extra functionalities of GD2 if present, but that might impact compatibility. To get back on the exact question, I do not know. May be there is some calls which give that information ? (or which do not return an error in such cases ?) } } 2) MODE 0 on the GD2 is monochrome. However, the system call to return the } mode, will return 0 for standard QL MODE 4 - how do we know which is which. Do you have any hardware which use mode(2,0) ? I only know of QXL/QPC: mode(2,32) and Q40/Q60: mode(2,33) And if you leave the conversion to the system, I really believe that you do not need to know the current mode at the application level: Especially, Imagine that your application has detected a mode and has performed some adaptation to it. And somehow, outside of your application, the user changed the mode after your adaptation, how are you going to react and prevent that ? Are you going to regularly check the current mode and readapt on the fly ? It is really simpler to have the system do that for your application, which means in first place that your application should not be aware of the current mode. Your application should make provision for both original QL and GD2 driver and leave the data structures upto the system to choose the best appearance. (so it can run on a classical QL too, if meaningfull [for instance, the sprite editor is not currently able to run on such mode]). } } 3) At present, there is no way of differentiating when a PIC file has been } saved using a GD2 colour scheme and when it has not. This causes problems } with the GD2 modes 0, 4 and 8. I would suggest that the unused byte at } offset 7 in the PIC file header is set to signify GD2 mode used. Offset 7 ? The pic format is: 0 Word tag : 4AFC 2 Word width 4 Word height 6 Word row 8 byte mode 9 byte spare So I guess that you are speacking of offset 9 rather than 7. It might be a good idea to use the spare byte for that distinction. Or we might have a stranger mode specification such as mode(2,0) is 255 and mode(2,8) is 254 (there is no conflict with 4, because QL mode 4 is stored as 0) 255 and 254 are arbitrary value, and we can choose whatever we want, as long as we get it documented and agreed by the Great Coordinator... } } 4) I presume that even if a palette mapped screen mode is used (7,15 or 31), } the program to create the PIC file does not need to concern itself, as it is } storing the pixel information PEEKed from the actual screen memory. Is this } correct, or should the PIC file be able to store the palette mapping } information?? I would not expect palette information to be stored with a pic file. It would mean that displaying such extended pic would overload the local palette, which is rather agressive behaviour (it would perturb the display of all the palette-based applications.) If palette independance is wanted, the user should export/convert the pic file in a fixed colour mode (such as 64: 24 bits per pixel, for example). But that's only my personal feelings. -- Grimbert Jérôme
