Hi
It may be a question that has been asked before, but what I am wondering is which mode is used for the 16 bit colours in themes. Have looked through Dilwyn's site and QToday without finding an answer. Are they mode 32 or if not what are they?
Why? I have been looking at updating EddIcon.
Thanks for any help.
Duncan
Themes
Re: Themes
While we wait for a more learned explanation, here is my understanding:
These are the new Wman colours, as described in the display_txt document in the SMSQ/E
sources. They are not of any particular "mode"; they are mode-agnostic codes. You can use
the following colour codes in any wman objects (and WM_xxx keywords):
Obviously, the actual colours displayed will have been converted to the native mode as per
disp_type 0, 8, 16, 32 or 33.
These are the new Wman colours, as described in the display_txt document in the SMSQ/E
sources. They are not of any particular "mode"; they are mode-agnostic codes. You can use
the following colour codes in any wman objects (and WM_xxx keywords):
Code: Select all
%00000000cccccccc exactly as before
%00000001pppppppp palette
%00000010pppppppp system palette
%00000011gggggggg gray scale
%00000100cc00tttd 3d border (border calls only!)
%01ssxxxxxxyyyyyy palette stipple. see below
%1rrrrrgggggbbbbb 15 bit RGB
disp_type 0, 8, 16, 32 or 33.
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: Themes
Hi Per,
Thanks for the pointer to that document, so if I now understand it correctly only the hex numbers in the saved theme files that have the first bit set are the 15 bit colours that are used for paper ink etc, while the other numbers are borders, stipples etc.
Thanks.
Thanks for the pointer to that document, so if I now understand it correctly only the hex numbers in the saved theme files that have the first bit set are the 15 bit colours that are used for paper ink etc, while the other numbers are borders, stipples etc.
Thanks.
Re: Themes
Hi Duncan,
Well, sort of: The Wman 15bit RGB colours dont correspond to those of any of the "natural" modes.
Since its quite complicated to unravel the Wman codes to convert them into real colours, and since
there are no hooks into the internal routines to do those conversions, I find the simplest way to
access the real colours is to set, say, the ink colour using WM_INK, and then get the resulting native
colour directly from the CDB with an xtop routine. This works ok for plain colours at least.
Well, sort of: The Wman 15bit RGB colours dont correspond to those of any of the "natural" modes.
Since its quite complicated to unravel the Wman codes to convert them into real colours, and since
there are no hooks into the internal routines to do those conversions, I find the simplest way to
access the real colours is to set, say, the ink colour using WM_INK, and then get the resulting native
colour directly from the CDB with an xtop routine. This works ok for plain colours at least.
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: Themes
Yes Duncan, that's correct.
Regarding the 15-bit RGB mapping, WMAN code is written device independent, so it needs to use the 24-bit TRAP calls to interface with the OS. For this to work there is a 5-to-8 bit RGB conversion table that maps the values 0..31 uniformly to 0..255. On the CON driver side this is then reduced again to 16-bit or 8-bit or whatever, so the results are somewhat difficult to predict at the bit level.
Regarding the 15-bit RGB mapping, WMAN code is written device independent, so it needs to use the 24-bit TRAP calls to interface with the OS. For this to work there is a 5-to-8 bit RGB conversion table that maps the values 0..31 uniformly to 0..255. On the CON driver side this is then reduced again to 16-bit or 8-bit or whatever, so the results are somewhat difficult to predict at the bit level.