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 future Aurora drivers, but, for the time being, I have no idea whether that will ever come true and, if so, implement true palette colours (and why not keep things simple?). The palette colours in modes 33 and 32 are translated into 16 bit colours when displayed an the screen. As was rightly pointed out, the pic files are just peeks of the actual screen memory. On 3 Jan 2003, at 18:48, Marcel Kilgus wrote: > > Have a look at keys_con "pt_ident". GD2 can be identified by > this. I'm > not sure however how "official" this solution is. But even then it > could be made official if we want. > So let's do that! Wolfgang
