Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 17:28:48 GMT Standard Time, [EMAIL PROTECTED] writes: Even so, it will sometimes be necessary to check for the presence of GD2 initially: I have had to deal with programs which need to know whther the mode is 4 or 8. When mode 33 appeared I changed the (assembler) code slightly to trap the modes 32 and 33. Unless GD2 modes 0,4 and 8 are used (are they really?) then the ordinary mode trap tells you the situation. Of course, if the low GD2 modes 0, 4 and 8 are used as machine native modes, then the mode trap should be extended in a universally accepted way. George rem Init if GD2 then blue = $70: : else blue = 0: rem Main ink#ch;blue This cant be done automatically without retro-engineering Qdos. Per
Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 10:05:36 GMT Standard Time, [EMAIL PROTECTED] writes: Which reminds me, has anyone else already written programs which output PIC files in the extended colour modes??? Yes, if my PSA files are in the same format as PIC files, as they seem to be. The programs are available on the SQLUG website. George
Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 17:28:48 GMT Standard Time, [EMAIL PROTECTED] writes: Even so, it will sometimes be necessary to check for the presence of GD2 initially: I have had to deal with programs which need to know whther the mode is 4 or 8. When mode 33 appeared I changed the (assembler) code slightly to trap the modes 32 and 33. Unless GD2 modes 0,4 and 8 are used (are they really?) then the ordinary mode trap tells you the situation. Of course, if the low GD2 modes 0, 4 and 8 are used as machine native modes, then the mode trap should be extended in a universally accepted way. George rem Init if GD2 then blue = $70: : else blue = 0: rem Main ink#ch;blue This cant be done automatically without retro-engineering Qdos. Per
Re: [ql-users] PIC File Format and GD2 Continued
On 3 Jan 2003, at 9:09, Jerome Grimbert wrote: } 1) What is the best way of detecting whether GD2 drivers are present } and in use?? For the time being, there seem only to be the WMAN version numbers. If you can wait a little, I should write a new trap soon (rest cut) OK, so that takes care of sprites. However, there still must be some way to know on what type of WMAN you're running, and what colours are available to your software. 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. No, of course not,a nd it seems that Marcel has taken extreme care when designing the new WMAN to make sure of cpmpatibility. However, if one is to make use of the new functionalities (such as different colours), one must know just where one stands. Why not use the MODE keyword as used in Basic? This will return some quite sensible values. The thing is that your software must be able to find out on what machine it is running - even if it is running on an old machine. Do you have any hardware which use mode(2,0) ? Yes, Atari monochrome. 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 ? You don't. If the user really changes the mode in such a drastic manner, then he might be expected to rstart the application as well. Let's not forget that in many cases this will not really be very important: doing a mode call on a high colour system (eg QPC or Qx0) doesn't really change the mode anyway -it'll still be mode 32 or 33 (even when using palette colours!). 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. How do you set the paper colour of a window without knowing what mode you're in? How do you know what colours are available? Perhaps the easiest way is to do this as follows: First, find you if you're running on SMSQ/E. (print ver$) If not, this can only be an old WMAN anyway, so you're restricted to 4 and 8 colours. Then do a read mode call and take it from there... 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... I'm open to suggestions! Again, I As I see it, there are several problems here. First of all, let's not confuse Sprites with Pics and Psaves (partial save areas), even though they may share some common ground. The problem,as I see it, is that, until now at least, none of these formats was designed to be used in another mode than the one it was used from. This is understandable for Psaves which are mainly used whilst a program is running, and for that program. For sprites, again, a provision is made by the system for having sprites in different modes, the system then automatically choosing the best one for the current mode, and possibly, adapting it (in the buffer) before displaying it. Jéröme is doing quite some work on that! That leaves PIC files. To my knowledge, and as pointedout above, they were not designed as some kind of interchangeable picture file format - even in the old days, you couldn't use it to display a mode 8 file on a mode 4 screen. Is that what is wanted? This will entail a certain number of conversion routines (which will be part of the application doing the displaying of the pic file). Do you want/need some help with that? } } 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?? For the time being, there simply are no palette mapped screens. OK, so there are some dark mutterings here and there about
Re: [ql-users] PIC File Format and GD2 Continued
[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
Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 08:08:37 GMT Standard Time, [EMAIL PROTECTED] writes: [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. Such a new TRAP would be ideal for normal graphics routines which call the SMSQ/E in-built routines for drawing. However, the problem comes with code which uses the IOW.XTOP routine to directly access the screen (such as we currently need to access the higher colour modes on Aurora and possibly the THOR). If you are writing a PIC file display routine in m/c, you have no choice, but to directly access the screen and write the information direct. This would therefore offer no possibility of utilising a TRAP call I presume (unless the TRAP will convert an entire area of memory across to the required colour modes - which is what I presume you are working on). This would need to be called before the IOW.XTOP routine, which would leave the possibility of the screen mode being changed in the meantime. Any chance that you could let me and Phoebus Dokos know (privately) what the TRAP routine would be expecting so that I and Phoebus can work on the necessary routines 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 am not aware of any - Jochen?? I only know of QXL/QPC: mode(2,32) and Q40/Q60: mode(2,33) There will also be Aurora: mode (2,16) and don't forget the palette mapped modes and modes (2,4) and (2,8)... 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 ? I thought that a graphics mode was allocated to a program when it was launched and later changes would not affect pre-existing programs Is this an incorrect assumption?? - looks desparately for the relevent section in the GD2 documentation.. section 2.3 - "The commands have no effect on any other programs executing". 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]). That would be wonderful, if it can be implemented in such a way as to allow both the extended colour modes and a mode compatible with the original QL } } 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. Yes, oops... I was tired... 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
Re: [ql-users] PIC File Format and GD2 Continued
In a message dated 03/01/03 08:08:37 GMT Standard Time, [EMAIL PROTECTED] writes: } } 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... I agree with this. How will the G... C... make His decision known? (This answers the question I have recently asked. Thanks.) } } 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. I would hope that a PIC file stores only information taken from the screen area, ie whatever COLOUR_NATIVE happens to be. George
Re: [ql-users] PIC File Format and GD2 Continued
[EMAIL PROTECTED] wrote: If you can wait a little, I should write a new trap soon Do you already have an API definition in mind? I only know of QXL/QPC: mode(2,32) and Q40/Q60: mode(2,33) There will also be Aurora: mode (2,16) and don't forget the palette mapped modes and modes (2,4) and (2,8)... Well, which hardware (except QPC, but I have that fairly good under control ;) ) could (even only in theory) ever use those palette mapped modes? I thought that a graphics mode was allocated to a program when it was launched and later changes would not affect pre-existing programs Is this an incorrect assumption?? Yes, it is. The driver works according to the highlander principle: There can be only one (format). Changing driver means changing format. I do *VERY HIGHLY* discourage changing display mode at all when applications other than SBASIC are running. - looks desparately for the relevent section in the GD2 documentation.. section 2.3 - The commands have no effect on any other programs executing. This section is not relevant, those commands DON'T change the display mode. Only the way some SBASIC commands interpret their parameters. I agree that is possibly the better solution, if there is an easy way of looking up the system palette to get the 24 bit information per pixel There is no palette mapped mode on any available hardware therefore I don't think this is much of a problem for PIC files. Marcel
Re: [ql-users] PIC File Format and GD2 Continued
Jerome Grimbert writes: If you can wait a little, I should write a new trap soon (as I said, the 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. I think this is an excellent principle - if it can be solved in a technically satisfactory way. Does anyone else have any thoughts on how this might impact? 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 ?) I suppose the only legal way at present is to query the DISP_xxx Thing. From SBasic: IF DISP_TYPE = 32: PRINT HI COLOR MODE However, from assembler its really quite an unnecessary fiddle to do. There really wants to be a system variable or a simple call for this, one that would be easy to implement as a dummy toolkit for older systems. 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]). Even so, it will sometimes be necessary to check for the presence of GD2 initially: rem Init if GD2 then blue = $70: : else blue = 0: rem Main ink#ch;blue This cant be done automatically without retro-engineering Qdos. Per
[ql-users] PIC File Format and GD2 Continued
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?? 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. 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. 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?? -- Rich Mellor RWAP Software 35 Chantry Croft, Kinsley, Pontefract, West Yorkshire, WF9 5JH TEL: 01977 610509 http://hometown.aol.co.uk/rwapsoftware
