Functions of colors with different results.... [EXPLAINED]

[TempodiBasic]

Hi guys

I'm writing something in graphic mode. The well suited graphic in QB64 is 32bit mode so I try to do something in that mode...

but I fall in this issue...
sorry but I am an hobbiest programmer and I don't know if these my results are right or a feature in developing of QB64 functions that calculate the value of the color as a long number (_RGB, _RGB32, _RGBA, _RGBA32)...
I have thought about them like math functions that return a value after getting some input values.... but I find that their results are different in front of their position before or after screen initialization... can the settings of the screen modify the results of these functions?

here two codes to show the issue...

Code: QB64: [Select]

1. CONST XMaxScreen = 600, YMaxScreen = 500, Opaque = 255
2. _TITLE " Functions of colors before screen settings"
3.  
4. DIM a(1 TO 4) AS LONG
5. a(1) = _RGB(255, 127, 27)
6. a(2) = _RGB32(255, 127, 170)
7. a(3) = _RGBA(255, 127, 220, Opaque)
8. a(4) = _RGBA(255, 127, 127, Opaque)
9. SCREEN _NEWIMAGE(XMaxScreen, YMaxScreen, 32)
10. FOR b = 1 TO 4 STEP 1
11.     LINE (10, 10 * b)-(300, 300 / b), a(b)
12.     LOCATE 1, 1: PRINT b: _DELAY .5
13. NEXT
14.  

Code: QB64: [Select]

1. CONST XMaxScreen = 600, YMaxScreen = 500, Opaque = 255
2. _TITLE " Functions of colors after screen settings"
3. SCREEN _NEWIMAGE(XMaxScreen, YMaxScreen, 32)
4. DIM a(1 TO 4) AS LONG
5. a(1) = _RGB(255, 127, 27)
6. a(2) = _RGB32(255, 127, 170)
7. a(3) = _RGBA(255, 127, 220, Opaque)
8. a(4) = _RGBA(255, 127, 127, Opaque)
9.  
10. FOR b = 1 TO 4 STEP 1
11.     LINE (10, 10 * b)-(300, 300 / b), a(b)
12.     LOCATE 1, 1: PRINT b: _DELAY .5
13. NEXT
14.  

here a screenshot attached  [ You are not allowed to view this attachment ]  
Thanks to read and to give feedback

[bplus]

Hi TempodiBasic,

_UNSIGNED LONG best type container for color values specially with alpha.

Color functions without 32 try to match best color to screen mode, if screen not set (like difference between your first code and 2nd) will get different results as you've shown.

You can get 4 colored lines for screen 12 on first code snip (even with LONG as color container):

Code: QB64: [Select]

1. CONST XMaxScreen = 600, YMaxScreen = 500, Opaque = 50
2. _TITLE " Functions of colors before screen settings"
3.  
4. DIM a(1 TO 4) AS LONG, c(1 TO 4) AS _UNSIGNED LONG
5. a(1) = _RGB(255, 127, 27)
6. a(2) = _RGB32(255, 127, 170)
7. a(3) = _RGBA(255, 127, 220, Opaque)
8. a(4) = _RGBA32(255, 127, 127, Opaque)
9. c(1) = _RGB(255, 127, 27)
10. c(2) = _RGB32(255, 127, 170)
11. c(3) = _RGBA(255, 127, 220, Opaque)
12. c(4) = _RGBA32(255, 127, 127, Opaque)
13.  
14. SCREEN 12 '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< get all 4 lines
15. FOR b = 1 TO 4 STEP 1
16.     LINE (10, 10 * b)-(300, 10 * b + 10), a(b), BF
17.     LINE (310, 10 * b)-(600, 10 * b + 10), c(b), BF
18.     LOCATE 1, 1: PRINT b: _DELAY .5
19. NEXT
20.  
21.  

EDIT: Sorry for all edits, still playing with code.

[SMcNeill]

The difference is screen mode.

In your first code, you’re doing this:

SCREEN 0
blah = _RGB...
blahblah = _RGB...
SCREEN _NEWIMAGE(x, y, 32)


Now, what value does those variables hold?

Since it’s for a screen 0 text screen, (the screen used before _RGB was called),  those color values are going to be something from 0 to 15.  (The only foreground values we have available...)

Now, when you swap to a 32-bit screen, is there *any* reason why those values would change??

Nope!  They’re still going to be the same as before — and in 32 bit mode, what *is* COLOR 15?

It’s 0 Alpha, 0 Red, 0 Green, 15 Blue — It’s almost a fully transparent black! 

*****************

RGB32, however, *doesn’t* care what screen mode you’re in.  It only returns the 32-bit color value for the _RGB(Red, Green, Blue) you specify.

_RGB gives you the closest match possible for your current screen mode and palette.  _RGB32 only returns back 32-bit color values.  It’s an inherent difference in the nature of the commands.

[Raven_Singularity]

I just ran into the same issue recently.  It was fairly confusing, as the related wiki pages didn't make it clear what the difference is between the two sets of RGB functions.  I think it would help people out a lot if the wiki help pages for _RGB_RGBA and _RGB32/_RGBA32 clearly explain the difference between them.  I've been reading technical manuals for decades, and it wasn't clear to me what the difference was.


Maybe something under Description like this would clarify things for new users:

• _RGB32/_RGBA32 functions always returns a colour value consisting of 8bit components for R, G, B (and A).
• _RGB/_RGBA functions return 8bit component values when in 32bit screen modes, but return the nearest matching palette entry number in screen modes with =< 256 colours.

[SMcNeill]

I just ran into the same issue recently.  It was fairly confusing, as the related wiki pages didn't make it clear what the difference is between the two sets of RGB functions.  I think it would help people out a lot if the wiki help pages for _RGB_RGBA and _RGB32/_RGBA32 clearly explain the difference between them.  I've been reading technical manuals for decades, and it wasn't clear to me what the difference was.


Maybe something under Description like this would clarify things for new users:

• _RGB32/_RGBA32 functions always returns a colour value consisting of 8bit components for R, G, B (and A).
• _RGB/_RGBA functions return 8bit component values when in 32bit screen modes, but return the nearest matching palette entry number in screen modes with =< 256 colours.

Here’s the basic difference:

_RGB and _RGBA returns the closest possible match to the values you specify — that the screen/image will allow.

For example, let’s use a SCREEN 0 screen. There’s a maximum of 16 colors in our palette, correct?  So what are these values?

_RGB(255,255,255)
_RGB(254,255,255)
_RGB(255,254,255)
_RGB(255,255,254)

In 32-bit color mode, those are all *very* subtle different colors of white.

But in SCREEN 0, where we only have dull white (COLOR 7) and bright white (COLOR 15), what’s the closest match to those _RGB values possible?

15
15
15
15

Screen 0 has a reduced palette set, so _RGB tries to find the closest possible match to display the color you specified from within that palette.  Same with the other screens, such as SCREEN 13 which has 256 colors in the palette — _RGB tries to match the best possible value to your specification.

*************

_RGB32 and _RGBA32, however, *only* return 32-bit color values, regardless of screen mode.  (Which is why it’s much faster to operate than _RGB, as it doesn’t have to check what mode and palette to return a match for.  It’s just simple math at work.)

**************

And that’s the basic difference in the two commands.  👍

[Raven_Singularity]

I understand the difference, now.  But the difference is unclear on the wiki, and I don't think the public can update the QB64 wiki directly, hence my suggestion to update it, so it's clear for future users.

[FellippeHeitor]

• _RGB/_RGBA functions return 8bit component values when in 32bit screen modes, but return the nearest matching palette entry number in screen modes with =< 256 colours.

The _RGB function returns the closest palette attribute index (legacy SCREEN modes) OR the LONG 32-bit color value (32-bit screens).

The _RGBA function returns the closest palette index (legacy SCREEN modes) OR the 32-bit LONG color value (32-bit screens).

I honestly see no difference except for wording.

[TempodiBasic]

Hi guys
Thanks to
@Bplus to stress the _UNSIGNED LONG is better than LONG variable type

_UNSIGNED LONG best type container for color values specially with alpha

@Steve (SmcNeill) to explain  with details and examples the difference between the two kind of color functions

RGB32, however, *doesn’t* care what screen mode you’re in.  It only returns the 32-bit color value for the _RGB(Red, Green, Blue) you specify.

_RGB gives you the closest match possible for your current screen mode and palette.  _RGB32 only returns back 32-bit color values

and

RGB32 and _RGBA32, however, *only* return 32-bit color values, regardless of screen mode.  (Which is why it’s much faster to operate than _RGB, as it doesn’t have to check what mode and palette to return a match for.  It’s just simple math at work

@Raven_Singularity to show in different way  my beginner's difficult to understand the difference and to loose my mind into wiki words, so I got the issue of the thread

Maybe something under Description like this would clarify things for new users:
_RGB32/_RGBA32 functions always returns a colour value consisting of 8bit components for R, G, B (and A).
_RGB/_RGBA functions return 8bit component values when in 32bit screen modes, but return the nearest matching palette entry number in screen modes with =< 256 colours.

@Fellippe to stress that what is written in wiki and what has been said in this thread are equivalent as meaning...
and I must admit that now, after well understood the difference, I can see that wiki is clear...
also if I need to ask again, I understood _UNSIGNED LONG is better than LONG, but is only LONG  wrong or less working?

wiki _RGB

The value returned is either the closest color attribute number or a 32-bit _UNSIGNED LONG color value.
Return variable types must be LONG or the resulting color may lose the _BLUE value.

wiki _RGBA

The value returned is either the closest color attribute number or a 32-bit _UNSIGNED LONG color value.
Return variable types must be LONG or resulting color may lose the _BLUE value.

wiki _RGB32

The value returned is always a 32-bit _UNSIGNED LONG color value, as is the POINT value.
Return variable types must be _UNSIGNED LONG or LONG, otherwise resulting color may lose the _BLUE value.

wiki _RGBA32

The value returned is a 32-bit _UNSIGNED LONG color value.
Return variable types must be LONG or resulting color may lose the _BLUE value.

Thanks I can affirm this forum is a rock!

[FellippeHeitor]

but is only LONG  wrong or less working?

Not wrong or less working, it's just going to give weird/confusing results when it returns negative values for some colors. Other than that it's perfectly fine to use LONG instead of _UNSIGNED LONG.

32BIT color values go up to the limit of _UNSIGNED LONG data type, that's why it's convenient to store them.

[SMcNeill]

When using colors, it’s always best to use _UNSIGNED LONG instead of just LONG variables.

Reason? 

Interaction with QB64 commands which return UL instead of L...

SCREEN _NEWIMAGE(640, 480, 32)
DIM Red AS LONG
Red = _RGB32(255, 255, 255)
PSET (0,0), Red

PRINT Red
PRINT POINT(0,0)


Run the above.  The values won’t match (unless PRINT formats them to match types.  Print is stupid sometimes with formatting...).  In an IF statement such as IF POINT(0,0) = Red THEN.... the result will return FALSE.

As a LONG, Red is a negative value.  POINT(x,y) is a large positive value.  They aren’t the same.

Change Red to _UNSIGNED LONG, and the issue will disappear.

[Raven_Singularity]

I honestly see no difference except for wording.

I was suggesting having those two bullets on all 4 wiki pages.  Currently you need to carefully compare the wiki pages to determine the difference between the functions.  By clearly specifying the diference between the sets of functions on all 4 pages, the user doesn't need to do a "Spot The Difference" game with the help pages.  The fact remains that new users even with technical experience are not understanding the difference.  If they were, the forums wouldn't be full of people being confused by these functions.

One of the best parts of QuickBASIC was how clear the documentation was.  I almost never encountered a function that I couldn't fully understand from the help page alone.  As a child, I learned QuickBASIC without any external help (books, chat forums, etc.).  There's no way I could have learned QB64 as a child (even now as an adult) without external help sources.

Understanding the wiki page after knowing how the functions work, or understanding them when you're a QB64 developer, is not the same as a new user trying to learn the language from scratch using the help pages.  I'm trying to offer you perspective on why these functions confuse new users, and a suggestion of how to avoid the confusion in future.

For an example of really clear documentation, check out php.net.  Every time there are similar or related functions, each of the function help pages clearly mentions how the functions differ from each other, and when it is appropriate to use one function over the other.