_SETALPHA Question

[TerryRitchie]

I seem to be having issues with _SETALPHA.

When I initially set a color to a transparency level with _SETALPHA I can't change it to another transparency level later on.

I'm certain I've done this in the past.

I've found a work-around using a temporary image but I'm sure this is not needed ... or is it? See my code below and please explain to me why the first block of code is not working. A bug? Brain-fart on my part?

Code: (Select All)

'|
'| Fade in a red box test
'|

DIM RedBox AS LONG
DIM TempBox AS LONG
DIM c AS INTEGER

SCREEN _NEWIMAGE(640, 480, 32)

RedBox = _NEWIMAGE(320, 240, 32)
_DEST RedBox
CLS , _RGB32(255, 0, 0)
_DEST 0

'c = 0 '                                       |
'DO '                                          | This block of code does not work?
'    CLS '                                     |
'    _LIMIT 30 '                               | The Wiki shows however this should be acceptable
'    _SETALPHA c, _RGB32(255, 0, 0), RedBox '  |
'    _PUTIMAGE (159, 119), RedBox '            |
'    _DISPLAY '                                |
'    c = c + 1 '                               |
'LOOP UNTIL c = 256 '                          |


c = 0 '                                       |
DO '                                          | This block of code does work.
    CLS '                                     |
    _LIMIT 30 '                               | Why do I need to copy the original RedBox to
    TempBox = _COPYIMAGE(RedBox) '            | to another image for every iteration of the loop?
    _SETALPHA c, _RGB32(255, 0, 0), TempBox ' |
    _PUTIMAGE (159, 119), TempBox '           |
    _DISPLAY '                                |
    _FREEIMAGE TempBox '                      |
    c = c + 1 '                               |
LOOP UNTIL c = 256 '                          |

[DSMan195276]

The alpha value of the color provided to `_SetAlpha` has to match what is already there. IE. After your first call to `_SetAlpha`, all the red pixels no longer have 255 alpha, and as a consequence they are not equal to `_RGB32(255, 0, 0)` which does (That's the same as `_RGBA32(255, 0, 0, 255)`).

You can get around this issue with the `TO color` option on `_SetAlpha`. Ex. I haven't tested it, but this should work: `_SetAlpha c, _RGBA32(255, 0, 0, 0) TO _RGBA32(255, 0, 0, 255), RedBox`.

I'm not 100% sure but I think the `_CopyImage` version works because it blends the images together and the resulting pixels still have 255 alpha, meaning the next `_SetAlpha` works as intended.

[TerryRitchie]

Well son of a pup that worked. Thank you.

The Wiki entry for _SETALPHA needs to be rewritten to make this more clear. I'm also going to need to revise Lesson 14 of the tutorial to reflect this information.

Code: (Select All)

'|
'| Fade in a red box test
'|

DIM RedBox AS LONG
DIM TempBox AS LONG
DIM c AS INTEGER

SCREEN _NEWIMAGE(640, 480, 32)

RedBox = _NEWIMAGE(320, 240, 32)
_DEST RedBox
CLS , _RGB32(255, 0, 0)
_DEST 0

c = 0
DO
    CLS
    _LIMIT 30
    _SETALPHA c, _RGBA(255, 0, 0, 0) TO _RGBA32(255, 0, 0, 255), RedBox
    _PUTIMAGE (159, 119), RedBox
    _DISPLAY
    c = c + 1
LOOP UNTIL c = 256

[TerryRitchie]

You know, I've been thinking about this. Having to work with _RGBA seems like overkill for something as simple as wanting to fade an individual color.

Why couldn't a statement such as

_SETALPHA Level%, _RGB32(255, 0, 0), Image&

automatically include all of the alpha levels from 0 to 255?

As it stands now you either need to enter a range with _RGBA as you have shown or manually keep track of every level change at each step in the software.

[SMcNeill]

SETALPHA Level%, _RGBA32(255, 0, 0, 0) TO _RGBA32(255,0,0,255), Image&

More flexibility than just assuming "do them all".  

What if you only wanted to change a single value's alpha?

[TerryRitchie]

SETALPHA Level%, _RGBA32(255, 0, 0, 0) TO _RGBA32(255,0,0,255), Image&

More flexibility than just assuming "do them all".  

What if you only wanted to change a single value's alpha?

Then that is where _RGBA32 would come into play. I definitely see the benefit of controlling individual alpha levels. What I envision is when _SETALPHA sees _RGB32 it assumes all alpha levels for the given color instead of the default 255 that is assumed with _RGB32.

_SETALPHA 0, _RGB32(255, 0, 0), Image& '           all alpha levels of red set to 0
_SETALPHA 0, _RGBA32(255, 0, 0, 255), Image& ' only alpha level 255 of red set to 0

I don't know, perhaps I'm overthinking this.

[SMcNeill]

One thing to remember, _RGB32 and RGBA32 just return a simple number for us to use.

Code: (Select All)

PRINT _RGBA32(255, 0, 0, 255)
PRINT _RGB32(255, 0, 0)
PRINT &HFFFF0000&&
PRINT 4294901760

All the above prints the same value for us -- 4,294,901,760 -- which represents the numeric value of "ALL Red and FULL Alpha".

Now, how is _SETALPHA going to recognize that that number in question came from _RGB, _RGBA, or some other formula?  Is it simply expected to assume that any time someone uses the value &HFFFF0000, that they intend to change the whole RGB spectrum for that color value, rather than just for &H00FF0000 TO &H11FF0000?  How the heck would they ever just change the alpha for &HFFFF0000 all by itself, if that's the *only* value they wanted to change??

[SMcNeill]

You can always do something like this, if you really just need to change alpha for a whole range at once for a _RGB color:

Code: (Select All)

OPTION _EXPLICIT

SCREEN _NEWIMAGE(640, 480, 32)





'|

'| Fade in a red box test

'|



DIM RedBox AS LONG

DIM c AS INTEGER



RedBox = _NEWIMAGE(320, 240, 32)

_DEST RedBox

CLS , _RGB32(255, 0, 0)

_DEST 0



c = 0

DO

    CLS

    _LIMIT 30

    ChangeAllAlpha c, _RGB32(255, 0, 0), RedBox

    _PUTIMAGE (159, 119), RedBox

    _DISPLAY

    _LIMIT 30

    c = c + 1

LOOP UNTIL c = 256



SUB ChangeAllAlpha (Alpha AS _UNSIGNED _BYTE, Kolor AS _UNSIGNED LONG, Image AS LONG)

    DIM AS _MEM m

    DIM AS _OFFSET o

    DIM AS _UNSIGNED _BYTE r, r1, g, g1, b, b1

    m = _MEMIMAGE(Image)

    r = _RED32(Kolor): g = _GREEN32(Kolor): b = _BLUE32(Kolor)

    o = m.OFFSET

    $CHECKING:OFF

    DO UNTIL o >= m.OFFSET + m.SIZE

        _MEMGET m, o + 2, r1

        _MEMGET m, o + 1, g1

        _MEMGET m, o, b1

        IF r = r1 AND g = g1 AND b = b1 THEN _MEMPUT m, o + 3, Alpha

        o = o + 4

    LOOP

    $CHECKING:ON

    _MEMFREE m

END SUB

[DSMan195276]

You know, I've been thinking about this. Having to work with _RGBA seems like overkill for something as simple as wanting to fade an individual color.

Why couldn't a statement such as

_SETALPHA Level%, _RGB32(255, 0, 0), Image&

automatically include all of the alpha levels from 0 to 255?

As it stands now you either need to enter a range with _RGBA as you have shown or manually keep track of every level change at each step in the software.

Personally I kinda agree, I think the marginal amount of flexibility gained is offset by it being extremely unintuitive that `_SetAlpha` still checks the original alpha value. I don't think I've ever seen someone use the ability to target specific alphas and this isn't the first time someone has run into this confusion and asked on this forum.

That said, we can't change it now. I think personally it's a bit of a silly command since it's just a big loop (so it's expensive), it's not something you want to be using often anyway.

[TerryRitchie]

You know, I've been thinking about this. Having to work with _RGBA seems like overkill for something as simple as wanting to fade an individual color.

Why couldn't a statement such as

_SETALPHA Level%, _RGB32(255, 0, 0), Image&

automatically include all of the alpha levels from 0 to 255?

As it stands now you either need to enter a range with _RGBA as you have shown or manually keep track of every level change at each step in the software.

Personally I kinda agree, I think the marginal amount of flexibility gained is offset by it being extremely unintuitive that `_SetAlpha` still checks the original alpha value. I don't think I've ever seen someone use the ability to target specific alphas and this isn't the first time someone has run into this confusion and asked on this forum.

That said, we can't change it now. I think personally it's a bit of a silly command since it's just a big loop (so it's expensive), it's not something you want to be using often anyway.

No, it's not very intuitive but I do see the need to allow the setting of individual alpha channel values. Instead of changing or adding to the _SETALPHA statement I think a better explanation in the Wiki would be a good alternative for now.

I'm currently reworking the _SETALPHA section in Lesson 14 of the tutorial. I completely had the explanation and example FUBARed because of the confusion I had. Yours and Steve's points and examples have set me straight.