_RGB

[krovit]

Hi,

I would point out that the _RGB instruction in my small program written months ago today shows strange behavior.

Specifically I report it, if it may be useful, that I had to replace almost all the instructions _RGB32(x,x,x) to _RGBA32(x,x,x,x) to avoid unwanted colors and overlays.

Maybe it will be a simple matter and I miss something but I do not think it can depend on my code because before it seemed to work everything perfectly.

After changing the code everything looks good.

[bplus]

A small code sample might be nice so we can see WTH you are talking about? ;-))

also are you working with QB64 v1.3?

Using _RGB depends on screen, using _RGB32 depends on using 32 bit color screens and graphics.

[krovit]

The version of QB64 was the 1.3 even before.

Incidentally: it would be possible to insert a string in the compiler with the version number from "QB64 COMPILER V1.3" to "QB64 COMPILER V1.3 xxx" ?

The only instruction that is between the before and after version (see attachments) is:

CONST mycolor& =_RGB32(122,127,175) (before)
And
CONST mycolor& =_RGBA32(122,127,175,255) (after)

Obviously before it didn't give any problem.

[SMcNeill]

Print out the actual values and see if they've changed at all for you:

Code: [Select]

CONST mycolor& = _RGB32(122, 127, 175)
CONST mycolor2& = _RGBA32(122, 127, 175, 255)
PRINT mycolor&, mycolor2&
_RGB32 and _RGBA32 just returns a set color for us, so it really shouldn't be the problem.  You can even calculate the result manually if you want to:  alpha * 255 ^ 3 + red * 255 ^2 + green * 255 ^ 1 + blue * 255 ^ 0

[bplus]

As I recall _RGB32 doesn't work that well for CONST, TempodiBasic running into problems a number of times and the & suffix is not best for 32 bit color and you don't need any suffix for CONST.

[Qwerkey]

You have always, I think, to be careful that a 32-bit colour is an _UNSIGNED LONG (mycolor~&), rather than LONG (mycolor&).  As Steve McNeill said, the value is [alpha * 255 ^ 3 + red * 255 ^2 + green * 255 ^ 1 + blue * 255 ^ 0] which is always positive.  Negative-going LONG (and using your values, mycolor& is -ve), might cause problems?

[krovit]

As I recall _RGB32 doesn't work that well for CONST, TempodiBasic running into problems a number of times and the & suffix is not best for 32 bit color and you don't need any suffix for CONST.

In my project the colors are obviously coded so color1, for example, is declared at the beginning and then applies in everything to all programs.

if I use
CONST Color1 = xxx
or
CONST Color1& = xxx
or
CONST Color1~& = xxx

the variable is remembered and the result is what we hoped for.

If I put it in a COMMON SHARED it is forgotten!
If I define it with TYPE it is not recognized!

I mean, in the end, it looks like he has to use CONST even if you tell me it's deprecated.
The only thing that really seems to affect the result is assigning _RGBA32 unsure of _RGB32

Anyway, thank you, I keep trying considering your observations.

[krovit]

You have always, I think, to be careful that a 32-bit colour is an _UNSIGNED LONG (mycolor~&), rather than LONG (mycolor&).  As Steve McNeill said, the value is [alpha * 255 ^ 3 + red * 255 ^2 + green * 255 ^ 1 + blue * 255 ^ 0] which is always positive.  Negative-going LONG (and using your values, mycolor& is -ve), might cause problems?

Negative values don't seem to cause problems (but I welcome your suggestion because I prefer them all to be positive).
There are no differences between the results by compiling out version 1.1, 1.2, and 1.3 of QB64.

I still don't understand why a simple _RGBA32 statement can give visual results so different than _RGB32
maybe it's my problem... sooner or later why it will become obvious.

Anyway I learned something new ;)
For now it's enough that everything works!

[SMcNeill]

In my project the colors are obviously coded so color1, for example, is declared at the beginning and then applies in everything to all programs.

if I use
CONST Color1 = xxx
or
CONST Color1& = xxx
or
CONST Color1~& = xxx

the variable is remembered and the result is what we hoped for.

If I put it in a COMMON SHARED it is forgotten!
If I define it with TYPE it is not recognized!

I mean, in the end, it looks like he has to use CONST even if you tell me it's deprecated.
The only thing that really seems to affect the result is assigning _RGBA32 unsure of _RGB32

Anyway, thank you, I keep trying considering your observations.

Can you share the whole code?  It seems to me, from what you say above, that the issue is one of scope with your variables.

Remember, COMMON SHARED is not the same as DIM SHARED.  Try changing those to DIM SHARED and see if the problem persists for you.

As for how _RGB32 and _RGBA32 give different results, I have no clue.  I'd need an example of the code which is producing the problem to be able to definitely diagnose what the issue might be.  They're both nothing more than simple math functions, so I imagine the problem is something besides them, though I have no idea what that might be beyond a scope issue.

[bplus]

Also consider my favorite declares for color:

CONST Red = &HFFFF0000, White = &HFFFFFFFF, Blue = &HFF0000FF, Yellow = &HFFFFFF00

[TempodiBasic]

Krovit  you can get more info about CONST issue at this thread https://www.qb64.org/forum/index.php?topic=1755.0
as Bplus have remembered.