}
} 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
