I am using S.M.'s DX9 subsystem. Found @ http://www.purebasic.fr/english/viewtopic.php?t=22184 . Unfortunately, the library only accepts hex longs aka $FFFFFF = white, $0 = Black, etc.
Using Hex will provide the correct colors on all video cards and color depths. Using Pb's RGB function does not provide the correct color on all video cards and color depths. For example, on one laptop rgb(255, 0, 0) produces a red color, on another, it produces a blue color.
Is there away to modify the RGB function on PB to return the correct color on all video cards? Or a way to convert the RGB function to provide a correct HEX (long) function?
RGB to valid (correct) Hex (long)?
Re: RGB to valid (correct) Hex (long)?
Let me guess, ... the one Notebook 'uses' BigEndian and the other 'Littleendian'? PC/MAC?Shannara wrote:IFor example, on one laptop rgb(255, 0, 0) produces a red color, on another, it produces a blue color.
Or its the issue that RGB also can be seen as GBR
Check out OOP support for PB here!
No, I promise you, there is no difference. PB's Rgb() function returns a colour in BGR format. There is no difference between using Rgb() and supplying a colour in BGR hex format. However, you can supply the colour in RGB hex format, then there will be a difference. By the way, the whole point of DirectX is that all cards accept BGR and BGR only no matter what the physical card accepts.Shannara wrote:Please try the two before commenting, TrondThere is a difference as previously mentioned.
As to answer inc. It's from PC to PC. Difference is some cards uses BGR others uses RGB and there is still the BRG cards, erk! It looks like PB doesn't take these into account.
Again, I assure you, there is absolutely no difference between PB's RGB() and supplying a colour in BRG hex format like this: $BBGGRR.
Since this is about a DirectX subsystem I can assure you that one of the laptops is not a mac.inc. wrote:Let me guess, ... the one Notebook 'uses' BigEndian and the other 'Littleendian'? PC/MAC?Shannara wrote:IFor example, on one laptop rgb(255, 0, 0) produces a red color, on another, it produces a blue color.
Or its the issue that RGB also can be seen as GBR
*** something is wrong somewhere. There shouldn't be a difference!
Edit: I have verified that RGB() command is working perfectly and that it gives a different result than using a hex colour. I must check what on earth happens to the hex colour.
Edit: No I was stupid. The RGB() command is still working perfectly and there is no difference between RGB() and $BBGGRR.
Edit: I have verified that RGB() command is working perfectly and that it gives a different result than using a hex colour. I must check what on earth happens to the hex colour.
Edit: No I was stupid. The RGB() command is still working perfectly and there is no difference between RGB() and $BBGGRR.
Can you post your code? It's literally impossible that there is a difference between PB's rgb() function and the hex thing.Shannara wrote:Ah, interesting indeed. Btw: Purebasic's HEX format is $RRGGBB. It works on my card and it is stated as such in the PB manual under Color TableHex works if I do it that way. Its when I use RGB... which is weird
I'll try to find some way to minipulate via hex instead of RGB.
Actually Shannara, the fact that the color table in the manual is RRGGBB is correct. But on a Little Endian system it is physically stored (in mem or on disk) as $00BBGGRR or is it $BBGGRR00
I hate intel to this very day for not choosing Big Endian like Motorola and IBM etc which in my eyes is the "proper way".
So. if you specify result=RGB($RRGGBB) then you are doing it correct,
if you later modify the result though you on your own
Also, there has been a few minor issues or confusions.
Certain image formats (or a few API calls even?) actually expect $RRGGBB00 format (Big Endian/Network byte order)
Search the forum for Big endian swap I (and a few others) did some routines, including a super easy ASM one for swapping the endianess of a long
(which is perfect for $RRGGBB00 and $00BBGGRR (PB's RGB($RRGGBB) actually) issues.
EDIT: http://www.purebasic.fr/english/viewtopic.php?t=14524
Here's a few big endian little endian swap functions.
PS! They are a bit old and ment for PB 3.x, if anyone feel like "porting" those functions/code to PB4 by all means go for it
Edit: updated the posts in that thread. PB4 and asm implementation of Endian() and EndianQ() available.
I hate intel to this very day for not choosing Big Endian like Motorola and IBM etc which in my eyes is the "proper way".
So. if you specify result=RGB($RRGGBB) then you are doing it correct,
if you later modify the result though you on your own

Also, there has been a few minor issues or confusions.
Certain image formats (or a few API calls even?) actually expect $RRGGBB00 format (Big Endian/Network byte order)
Search the forum for Big endian swap I (and a few others) did some routines, including a super easy ASM one for swapping the endianess of a long
(which is perfect for $RRGGBB00 and $00BBGGRR (PB's RGB($RRGGBB) actually) issues.
EDIT: http://www.purebasic.fr/english/viewtopic.php?t=14524
Here's a few big endian little endian swap functions.
PS! They are a bit old and ment for PB 3.x, if anyone feel like "porting" those functions/code to PB4 by all means go for it

Edit: updated the posts in that thread. PB4 and asm implementation of Endian() and EndianQ() available.