[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
