09-30-2023, 02:00 PM
(This post was last modified: 09-30-2023, 02:30 PM by TerryRitchie.)
(09-30-2023, 11:19 AM)SMcNeill Wrote:Thank you for looking things over. Making the change now.Quote:As a rule of thumb when working in 32 bit screens use _RED32, _GREEN32 and _BLUE32, and when working in non 32 bit screens use _RED, _GREEN, and _BLUE.
You may want to reword this a little bit. "rule of thumb" says to me that it's *recommended* behavior, not *required*.
When dealing with a non 32-bit screen, you *have* to use _RED. _GREEN, _BLUE to get back your index values. Let's take a SCREEN 0, Red pixel, for example:
With _RGB(4), you're going to get a return value of 255. This looks up the screen, checks the palette for index 4, and returns the RGB value associated with red for that palette.
With _RGB32(4), you're going to get a return value of 0. _RGB32 *only* works with 32-bit values, so this number is going to be counted as &H00000004. Zero alpha, zero red, zero green, and 4 blue. That's almost as close to transparent black as possible!
With non 32-bit screens, one *has* to use _RED, _GREEN, _BLUE. It's not really a "point of thumb"; in this case, it's a "fact".
With 32-bit screens, one *can* use either _RED, _GREEN, _BLUE, or _RED32, _GREEN32, _BLUE32 -- but the _32 commands are always going to be much quicker and faster for them.
Update: Changes made