[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 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 would prefer to use the spare byte - yet another possible colour mode in the header could cause even more confusion.. It would be simpler for programs which support the extended colour modes to simply check on the status of this byte...
Which reminds me, has anyone else already written programs which output PIC files in the extended colour modes???
}
} 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 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....
--
Rich Mellor
RWAP Software
35 Chantry Croft, Kinsley, Pontefract, West Yorkshire, WF9 5JH
TEL: 01977 610509
http://hometown.aol.co.uk/rwapsoftware
