Transitions for slideshow? (fades, slides, etc..)

You would need to use roScreen, and exclude your channel from 3.1 firmware devices as they will not be able to do smooth crossfades, you can set an alpha blending value when you call drawObject or DrawScaledObject.

For all devices both new and old you should be able to do slide-in transitions fairly easily. Using a double-buffered screen will make for a better visual effect as it won't draw in between screen refresh.

- Joel

"RokuJoel" wrote:
... 3.1 firmware devices as they will not be able to do smooth crossfades

What does that mean, details?
I am exploring alpha blending but don't remember seeing this in the docs, what are the 3.1 limitations regarding Alpha's?

"EnTerr" wrote:

"RokuJoel" wrote:
... 3.1 firmware devices as they will not be able to do smooth crossfades

What does that mean, details?
I am exploring alpha blending but don't remember seeing this in the docs, what are the 3.1 limitations regarding Alpha's?

It's not documented, but DrawObject (and all variants) will accept and additional alpha parameter. That parameter isn't supported on 3.1, so you wouldn't be able to do a crossfade. It'd also cause a crash if you tried passing the parameter on 3.1, so you'd either need to call it conditionally, or exclude 3.1 devices altogether.

"TheEndless" wrote:
It's not documented, but DrawObject (and all variants) will accept and additional alpha parameter. That parameter isn't supported on 3.1, so you wouldn't be able to do a crossfade. It'd also cause a crash if you tried passing the parameter on 3.1, so you'd either need to call it conditionally, or exclude 3.1 devices altogether.

Intriguing... do you know if that extra param works on non-OpenGL fw5 devices, like the 27xx series?

"EnTerr" wrote:

"TheEndless" wrote:
It's not documented, but DrawObject (and all variants) will accept and additional alpha parameter. That parameter isn't supported on 3.1, so you wouldn't be able to do a crossfade. It'd also cause a crash if you tried passing the parameter on 3.1, so you'd either need to call it conditionally, or exclude 3.1 devices altogether.

Intriguing... do you know if that extra param works on non-OpenGL fw5 devices, like the 27xx series?

It does.

crossfade two things:

screen.SetAplhaEnable(true)
for i = 0 to 255
hexcolor = &hFFFFFFFF - i
hexcolor2  = &hFFFFFF00 + i
screen.Clear(&hebebebFF)
screen.drawobject(0, 0, objectfadeout, hexcolor)
screen.drawobject(0, 0, objectfadein, hexcolor2)
screen.SwapBuffers()
end for

"TheEndless" wrote:

It's an RGBA value in the range of &HFFFFFF00 to &HFFFFFFFF. No idea what the RGB portion is for. This has no effect on the destination AlphaEnable state. It should behave the same as it would if you were drawing an image that was already semi-transparent (i.e., blend pixels if AlphaEnable is true, replace pixels if AlphaEnable is false).

They probably left it in to be consistent (!) since you can fade text and rectangles etc. where the color would be needed - not just bitmaps.

"TheEndless" wrote:
It's an RGBA value in the range of &HFFFFFF00 to &HFFFFFFFF. No idea what the RGB portion is for. This has no effect on the destination AlphaEnable state. It should behave the same as it would if you were drawing an image that was already semi-transparent (i.e., blend pixels if AlphaEnable is true, replace pixels if AlphaEnable is false).

Thank you for showing the known working values (ditto squirreltown for the example). What about the alpha channel of the source bitmap, does it get ignored - or honored (i.e. doing blending both by parameter and source pixel alpha)?

Here is a theory on the RGB part - those could be per-color-channel alphas, i.e. you can color-tint the image by using non-FFFFFF values. Or say doing 0xFF0000FF will give you only the red plane... and maybe with some luck 0x000000FF imprints only the alpha plane? (that would be fantastic)

I know if you have transparent parts of the bitmap, they remain transparent through the fade, as long as screen.SetAlpha is true. I don't think color tinting a bitmap works if i read you right, the Roku seems to ignore the color part of the hex string if its a bitmap - if you set a bitmap color to &hFFFFFFFF or &h000000FF it looks the same.

"squirreltown" wrote:
I don't think color tinting a bitmap works if i read you right, the Roku seems to ignore the color part of the hex string if its a bitmap - if you set a bitmap color to &hFFFFFFFF or &h000000FF it looks the same.

It works for me. If it didn't, this would be an all-white frame - since in generating code, A is the same and i tweak only R and G channels of the mask:

Der Programmcode:

    bitmap = CreateObject("roBitmap", {width: 100, height: 100})
    bitmap.Clear(&hFFFFFFFF)
    
    screen = CreateObject("roScreen")
    for i = 0 to 255
        screen.DrawObject(50 + 512-2*i, 50 + 0, bitmap, RGBA(255, 255-i, 0, 255))
        screen.DrawObject(50 + 0, 50 + 512-2*i, bitmap, RGBA(i, 0, 0, 255))
        screen.DrawObject(50 + 2*i, 50 + 512,   bitmap, RGBA(0, i, 0, 255))
        screen.DrawObject(50 + 512, 50 +2*i,    bitmap, RGBA(255-i, 255, 0, 255))
        'screen.finish()
    end for
    screen.finish()
    wait(0, screen.getPort())

Where RGBA of course is

function RGBA(r, g, b, a)
    return &h1000000*r + &h10000*g + &h100*b + a
end function

PS. bonus points if someone can explain why this code works always on Roku3 (4200) - but same code on HDMI stick (3500) shows the roScreen in only about 40-50% of the time, rest of the cases channel stays in "Loading..." screen forever (=till exiting manually). Seems like a nasty race condition bug.