The Icon Bar: Programming: Changing graphics foreground colour using OS_SetColour
|
Changing graphics foreground colour using OS_SetColour |
|
Cauchy (15:50 23/3/2013) thesnark (11:10 24/3/2013) Cauchy (00:51 25/3/2013) Cauchy (18:49 26/3/2013) thesnark (14:38 29/3/2013) thesnark (14:42 29/3/2013) Cauchy (17:43 29/3/2013) thesnark (19:14 29/3/2013) Cauchy (22:21 29/3/2013) thesnark (09:38 30/3/2013) Cauchy (23:47 30/3/2013)
|
|
John O'Meara |
Message #122105, posted by Cauchy at 15:50, 23/3/2013 |
Member
Posts: 43
|
void setGrapgicsCol(plotAction bits0_3, bGround bit4, int paletteEntry) { _kernel_swi_regs inregs, outregs; int flags = 0; // clear all bits
flags = bits0_3; flags = flags || bit4; inregs.r[0] = paletteEntry; _kernel_swi(ColourTrans_ReturnColourNumber, &inregs, &outregs); inregs.r[1] = outregs.r[0]; // pass col' no., into r1 inregs.r[0] = flags; _kernel_swi(OS_SetColour, &inregs, &outregs); } The above program code runs without any errors but fails to change the colour. plotAction and bGround are enum types. 'plotAction' is 0 for overwrite, and 'bGround' is 0 for foreground. bits 5,6 and 7 of the flags are all zero. OS_SetColour pages are 1-754 and 5a-116 of the PRM. Any help would br appreciated. Thank you. P.S., I callit like setGraphicsCol(0, 0, 0xff00); // I think 0xffoo is red.
[Edited by Cauchy at 16:02, 23/3/2013] |
|
[ Log in to reply ] |
|
Christopher Bazley |
Message #122112, posted by thesnark at 11:10, 24/3/2013, in reply to message #122105 |
AA refugee
Posts: 11
|
The || operator is logical OR, not bitwise OR. You want |. ________ Christopher Bazley |
|
[ Log in to reply ] |
|
John O'Meara |
Message #122116, posted by Cauchy at 00:51, 25/3/2013, in reply to message #122112 |
Member
Posts: 43
|
I changed that to the bitwise OR, i.e., flags = flags | bit4;. And ran the program code again. It ran without errors but failed to change the graphics foreground colour. It is an Iyonix computer that I use. I press the F12 key to access the * prompt and type in the program name to run it. I assume that one supplies a colour in the form BBGGRR00 as a palette entry and that ColourTrans_ReturnColourNumber returns a colour number for it. This number is then used by OS_SetColour to set the foreground or background according to the value of the flags' bits given to R0. The colour number is given in R1! I have since tried vdu18, that is the equivalent of it in C which is also for selecting graphics foreground and background colours and it works. The only thing is that the vdu 18 style is not recomended but OS_SetColour is. I am just wondering if any one else had any problems with OS_SetColour or any other newer swis like ColourTrans_ReadPalette which is to be used instead of OS_Word11 to make full use of the 16bpp and 32bpp modes now available?
[Edited by Cauchy at 01:01, 26/3/2013] |
|
[ Log in to reply ] |
|
John O'Meara |
Message #122143, posted by Cauchy at 18:49, 26/3/2013, in reply to message #122116 |
Member
Posts: 43
|
So I am now thinking if I may have to call anothe swi or vector along with OS_SetColour to effect OS_SetColour's operation, just like the PRM example on page 1-110 calls the paletteV vector and then calls OS_ReadPalette, but that is in assembly, and I don't know assembly, it would be better if it was in basic or C, so I not sure. Also I cannot get ColourTrans_ReadPalette to work even though "it is the is the recommended of doing so". It appears that I can get the paletteV vector to read the palette enteries alright! Any suggestions on these two swis would be welcome. Thanks. |
|
[ Log in to reply ] |
|
Christopher Bazley |
Message #122173, posted by thesnark at 14:38, 29/3/2013, in reply to message #122116 |
AA refugee
Posts: 11
|
I'm almost certain that there are ColourTrans SWIs to set colours directly from a palette entry and you could save yourself a lot of trouble (and the overhead of two SWI calls) by using those.
You need to read the documentation, not do assuming.
From the documentation of my Javascript colour converter at http://starfighter.acornarcade.com/convert/ I see that VDU 18 requires GCOL and TINT to be specified separately for 256 colour screen modes, whereas ColourTrans_ReturnColourNumber returns colours with a completely different bit-order optimised for the video hardware. |
|
[ Log in to reply ] |
|
Christopher Bazley |
Message #122174, posted by thesnark at 14:42, 29/3/2013, in reply to message #122116 |
AA refugee
Posts: 11
|
Why don't you read this? http://www.riscosopen.org/wiki/documentation/show/OS_SetColour%20Flags
Note that naming a variable 'bit4' is meaningless to the compiler. It doesn't know that you want to shift that value into bit 4. |
|
[ Log in to reply ] |
|
John O'Meara |
Message #122176, posted by Cauchy at 17:43, 29/3/2013, in reply to message #122174 |
Member
Posts: 43
|
Thanks for the reply and the links. The variable bit4 has its bit 4 clear or set according to whether you want to select the foreground or background. The bit 4 of variable bit4 (confusing alright) should be clear if you want foreground; this is done by setting the variable bit4 = 0;. To select background set the variable bit4 = 0x10;, i.e., 16. This means its bit 4 is now 1 and all other bits of the variable bit4 are zero. However, to select: set colour ,graphics, colour number, foreground and overwrite, the variable flags = 0; is the value that does all that, and then calling OS_SetColour, should work; there is no need to bitwise OR or shift any bits in that case. But as I said in earlier posts OS_SetColour does not execute the desired effect.Now according to the PRM 5a, VDU 17 and VDU 18; "These calls have not been extended to work in 16bpp and 32bpp modes; in such cases they will behave as if in an 8bpp mode. This makes the calls no longer useful, and you should instead use OS_SetColour and OS_SetColour. The colour number to be used can be found by using ColourTrans_ReturnColourNumber". Which is what I am attempting to do. I have got colour changes using ColourTrans_SetColour and ColourTrans_SetTextColour, but they use GCOL numbers and not colour numbers. Now, according to PRM page 5a-689; "Applications should not use GCOLs; they should instead deal with RGB palette enteries and colour numbers." So I am probably caught again. Thanks again. |
|
[ Log in to reply ] |
|
Christopher Bazley |
Message #122179, posted by thesnark at 19:14, 29/3/2013, in reply to message #122176 |
AA refugee
Posts: 11
|
Just use ColourTrans_SetGCOL with flags bit 8 set like everyone else, and ignore the return values. You'll tie yourself in knots if you start worrying about the difference between colour numbers and GCOLs. |
|
[ Log in to reply ] |
|
John O'Meara |
Message #122188, posted by Cauchy at 22:21, 29/3/2013, in reply to message #122179 |
Member
Posts: 43
|
So,just use ColourTrans_SetGCOL and forget about OS_SetColour which doesn't really work anyway. Thanks again. |
|
[ Log in to reply ] |
|
Christopher Bazley |
Message #122202, posted by thesnark at 09:38, 30/3/2013, in reply to message #122188 |
AA refugee
Posts: 11
|
So,just use ColourTrans_SetGCOL and forget about OS_SetColour which doesn't really work anyway. Thanks again. I'm sure that OS_SetColour works - I just can't be bothered to figure out why it doesn't work for you. |
|
[ Log in to reply ] |
|
John O'Meara |
Message #122218, posted by Cauchy at 23:47, 30/3/2013, in reply to message #122202 |
Member
Posts: 43
|
Hi, After you saying "I'm sure thta OS_SetColour works", I decided to go back to the problem. And I solved it by calling it twice like this: setGraphicsCol(0, 0, 0xff0000); setGraphicsCol(0, 0, 0xff0000);. I don't know the explanation for why one needs two successive calls to get it to work. |
|
[ Log in to reply ] |
|
|
The Icon Bar: Programming: Changing graphics foreground colour using OS_SetColour |