_SETALPHA Question

[TerryRitchie]

I just finished correcting the _SETALPHA statement in the Lesson 14 tutorial. I also added another example program to this section highlighting the _SETALPHA use examples discussed here.

[SMcNeill]

@TerryRitchie

While writing this lesson it was brought to my attention that the _RGB32 statement gained the ability to optionally work with the alpha channel rendering the need for _RGBA32 obsolete. _RGBA32 is still maintained for compatibility reasons however.

One thing to point out here -- *most* of the parameters for _RGB32 are optional now, with the number that you use affecting the result greatly.

color = _RGB32(value) <-- This is perfectly valid now, even though you didn't supply 3 values. In this case, what you're getting back is a GRAYSCALE color, which would be the same as: _RGB32(value, value, value).

color = _RGB32(value, alpha) <-- If you just supply two numbers, RGB32 will return a GRAYSCALE color back to you, *with* ALPHA levels. It's equivalent to: _RGBA32(value, value, value, alpha)

_RGB32(red, green, blue) <-- You covered this one, I think.

_RGB32(red, green, blue, alpha) <-- Same with this. You've already covered it.

---

I don't know if you want to include the two grayscale options with the _RGB tutorial, but I thought I'd mention them as they might be something folks should be aware of -- for debugging, if nothing else! After all, Kolor = _RGB32(red, greenblue) *would* work perfectly fine and with zero indication of any sort of error being involved where the user skipped the comma between the green and blue. I'm certain the result isn't going to be what they expect, but QB64PE *will* compile and run it with zero issues.

[SMcNeill]

There are also corresponding _RED, _GREEN, and _BLUE statements for working with 256 color images. These three statements will return the palette index of an 8bit (256) color.

Clarification here:

_RED, _GREEN, _BLUE return the *exact* same results as _RED32, _GREEN32, _BLUE32 while on a 32-bit screen.

Code: (Select All)

SCREEN _NEWIMAGE(640, 480, 32)

CLS , _RGB32(11, 22, 33)

DIM p AS _UNSIGNED LONG

p = POINT(0, 0)

PRINT _RED(p), _GREEN(p), _BLUE(p)

PRINT _RED32(p), _GREEN32(p), _BLUE32(p)

Run the above and you'll see that the return value is *exactly* the same with both sets of functions.

There is, however, one huge reason to use the 32 functions when possible -- they're MUCH faster!!

What _RED, _GREEN, _BLUE does is basically:

Take a point value...
Look up the palette value for that particular screen.
Convert that value over to a 256 color index.  (Say for screen 0 where RED might be 4.)
Return that converted value back to us.

What RED32, _GREEN32, _BLUE32 does is basically:
Assume the value you give it is a 32-bit color value.
Work basic bit shifting math and return the desired portion.  (Say you want the _RED32 value of a color.  Shift left 8 bits to strip off the alpha level.  Shift right 16 bits to strip off the green and blue level.  All that's left is the red value.)

Both will reach the same endpoint on 32-bit screens; it's just that the _32 functions will get there faster since they can bypass several if checks and such that are in the _non32 functions.

(And _RED, _GREEN, _BLUE work on *ALL* screen modes -- even SCREEN 0.  They're not just for 256 color screens like you implied here.)

[TerryRitchie]

Thank you for the insights Steve. Looks like I have more editing to do.

[TerryRitchie]

Ok Steve, I believe I have made all the changes in Lesson 14 that incorporate the items you pointed out to me. When you get a free moment please look them over and let me know if there is still any wording I need to clarify.

[SMcNeill]

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.

[TerryRitchie]

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.

Thank you for looking things over. Making the change now.

Update: Changes made