Author Topic: _RGB  (Read 4339 times)

0 Members and 1 Guest are viewing this topic.

Offline krovit

  • Forum Regular
  • Posts: 179
    • View Profile
_RGB
« on: December 18, 2019, 11:17:09 am »
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.


« Last Edit: December 18, 2019, 11:18:44 am by krovit »
Nothing is easy, especially when it appears simple (and nothing could be as dangerous as trying to do good to others)

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: _RGB
« Reply #1 on: December 18, 2019, 11:30:19 am »
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.
« Last Edit: December 18, 2019, 11:32:19 am by bplus »

Offline krovit

  • Forum Regular
  • Posts: 179
    • View Profile
Re: _RGB
« Reply #2 on: December 18, 2019, 11:54:59 am »
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.



Nothing is easy, especially when it appears simple (and nothing could be as dangerous as trying to do good to others)

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: _RGB
« Reply #3 on: December 18, 2019, 12:26:31 pm »
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
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: _RGB
« Reply #4 on: December 18, 2019, 12:56:53 pm »
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.
« Last Edit: December 18, 2019, 12:58:58 pm by bplus »

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Re: _RGB
« Reply #5 on: December 18, 2019, 12:58:18 pm »
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?

Offline krovit

  • Forum Regular
  • Posts: 179
    • View Profile
Re: _RGB
« Reply #6 on: December 19, 2019, 02:23:56 am »
Quote
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.


« Last Edit: December 19, 2019, 02:57:45 am by krovit »
Nothing is easy, especially when it appears simple (and nothing could be as dangerous as trying to do good to others)

Offline krovit

  • Forum Regular
  • Posts: 179
    • View Profile
Re: _RGB
« Reply #7 on: December 19, 2019, 03:08:35 am »
Quote
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!





Nothing is easy, especially when it appears simple (and nothing could be as dangerous as trying to do good to others)

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: _RGB
« Reply #8 on: December 19, 2019, 03:26:52 am »
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.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: _RGB
« Reply #9 on: December 19, 2019, 04:56:04 am »
Also consider my favorite declares for color:

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

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: _RGB
« Reply #10 on: December 19, 2019, 07:05:49 pm »
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.
Programming isn't difficult, only it's  consuming time and coffee