Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / dbRGB backwards

Author
Message
DaveyPocket
16
Years of Service
User Offline
Joined: 13th Jan 2008
Location:
Posted: 20th Aug 2008 03:10
I've noticed that the command, dbRGB is a little messed up.
When I went to color an object red, using dbRGB (255,0,0), it made it blue, when I changed it to blue, using dbRGB (0,0,255), it made it red. It seems like it's backwards. How would I fix this?
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 20th Aug 2008 04:38
It depends what you use it with, some things in GDK use big endian, some use little so you can't get a one-size fits all solution. You could just make 2 macros or functions to generate the values too.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 20th Aug 2008 05:32
It's never done that with me. On the other hand I prefer to use a macro like

#define RGB(r,g,b) 255<<24 | r<<16 | g<<8 | b

or the same as an inline function.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
DaveyPocket
16
Years of Service
User Offline
Joined: 13th Jan 2008
Location:
Posted: 20th Aug 2008 06:35
I've noticed this happening when you use the 'dbColorObject' command, when I wanted my object to become red, I typed 'dbColorObject ( 1, RGB (255,0,0) );'. The object should have been made red, but it was made blue. I now know how to fix this, but this is more of just a head's up to any other people experiencing this.
elantzb
16
Years of Service
User Offline
Joined: 10th May 2008
Location: Classified
Posted: 22nd Aug 2008 06:45 Edited at: 22nd Aug 2008 06:46
Quote: "#define RGB(r,g,b) 255<<24 | r<<16 | g<<8 | b"


now that is some macro syntax i haven't seen before!

please divulge!

~you can call me lantz~
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 22nd Aug 2008 07:12
The << is a shift operator. It says to shift the binary digits in the integer value to the left by the number of places on the right of the operator. So the first one says take the value 255 and shift it 24 binary digits to the left. This basically sets up the alpha channel to full opacity.

255 << 24 (shift the value 255, or 0xFF, to the left 24 binary digits)
r << 16 (shift the r, or red, value 16 binary digits to the left)
g << 8 (shift the g, or green, value 8 binary digits to the left)

We then OR all these values together with the unshifted b, or blue, value to get a complete unsigned int.

The benefit is that shifting is a quicker form of multiplying if the multiplier is a power of 2. The ORing acts as an addition as long as its components don't occupy overlapping bit segments.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 22nd Aug 2008 07:30
Quote: "#define RGB(r,g,b) 255<<24 | r<<16 | g<<8 | b"


Quote: "now that is some macro syntax i haven't seen before!"


I understand bit-operations, but I am curious why you didn't format it like this:



Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Aug 2008 07:38


It's better to use the top one here(as Mahoney wrote) to prevent any possible issues with underlying code from where it's referenced, but the 2nd isn't, as operator precedence ensures the bit-shifts will be performed first, but it can help with clarity I guess.

Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 22nd Aug 2008 08:00
Quote: "It's better to use the top one here(as Mahoney wrote) to prevent any possible issues with underlying code from where it's referenced, but the 2nd isn't, as operator precedence ensures the bit-shifts will be performed first, but it can help with clarity I guess."


I was just concerned with clarity, but I suppose it could prevent issues.

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 22nd Aug 2008 08:02 Edited at: 22nd Aug 2008 08:03
The ORing is a bitwise operation and, from my perspective, performs faster than the addition operation. The lack of parenz is because the shift operator binds more closely than the OR operator and thus assures that all the shift operations are performed before the OR.

Typically when you have bit definitions of options that can be combined, like:

#define MOTOR_ON 0x01
#define LIGHT_ON 0x02

When both, or others, can be passed to a function together you can pass them combined, yes, by addition. However, more often than not you'll see them passed in combination as:

Control (MOTOR_ON | LIGHT_ON);

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 22nd Aug 2008 16:44 Edited at: 22nd Aug 2008 16:51
I do it similar to how Lilith does it.

If you're doing a bitwise operation you should be using a bitwise operator, for both semantic reasons and to let the compiler know what you're trying to do so that it may optimize it.

Quote: "It's better to use the top one here"

No, it's not. The operator precedence is ambiguous here, and the compiler even tells you this. Let me show you the problem:



Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 22nd Aug 2008 17:46 Edited at: 22nd Aug 2008 17:47
Quote: "No, it's not. The operator precedence is ambiguous here"


I knew there was a reason I used the second one.

Quote: "The ORing is a bitwise operation and, from my perspective, performs faster than the addition operation. The lack of parenz is because the shift operator binds more closely than the OR operator and thus assures that all the shift operations are performed before the OR."


I simply find it clearer to use +'s. That was my point.

Quote: "When both, or others, can be passed to a function together you can pass them combined, yes, by addition. However, more often than not you'll see them passed in combination as:

Control (MOTOR_ON | LIGHT_ON);"


For controlling variables/registers, that is the way to go. For instance, when writing programs for the GameBoyAdvance, this sort of thing is common.



Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 22nd Aug 2008 18:11
So why not use it in other situations? I will admit, as I have in the past, that I'm a stickler for speed and thus try to do things in the way I perceive as fastest, though I may be wrong as to how the compiler or CPU actually handles such operations. ORing just seems to be a faster operation.

Shifting is almost always faster than multiplication because, as I understand it, the CPU has to do multiple, conditional shifts for generic multiplication operations. In some instances where I needed speed and I needed to multiply by ten I'd do something like.



In this case I can't OR the shifted values because I have no guarantee that their bit segments don't overlap.

AAR, based on Benjamin's comments I'd like to revise my macro a bit.

#define RBG(r,g,b) 255<<24 | (r)<<16 | (g)<<8 | (b)

This means that when the macro is expanded it will put parenz around the expanded expression of r, g and b to make them self-contained and preserve their original intent.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 23rd Aug 2008 02:45
Quote: "No, it's not. The operator precedence is ambiguous here, and the compiler even tells you this. Let me show you the problem:"


Oops, didn't see that he edited more than just the brackets, I assumed the bitwise ORs were still there, so yes, when using + you'd have to use brackets.

SunDawg
19
Years of Service
User Offline
Joined: 21st Dec 2004
Location: Massachusetts
Posted: 24th Aug 2008 06:14
I'd just like to point out that for GDK text operations, 2D, what-have-you, using RGB() will not return the same value as dbRGB(). I would hazard a guess that if you are getting blue when expecting red, you are using RGB() and not dbRGB().


My site, for various stuff that I make.

Login to post a reply

Server time is: 2024-09-30 05:19:37
Your offset time is: 2024-09-30 05:19:37