Roku Developer Program

[jayseattle]

I've searched the forum/sdk docs but have not found anything other than some topics suggesting drawing a solid on another layer and decreasing opacity as well as some transitions in the "BrightScreen" (sorry don't remember the name) products.

thanks

[RokuJoel]

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

[EnTerr]

"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?

[TheEndless]

"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.

[EnTerr]

"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?

[TheEndless]

"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.

[EnTerr]

"TheEndless" wrote:

"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.

So it must be there to stay and it's about time they document that parameter. Too many things to ask w/o doc
- What kind of value has to be passed? It did not seem to be 1 octet only for Alpha. Is it RGBA and if so what's the role of RGB there.
- Do all the other alphas get ignored when that param is present (i.e. destination's alphaEnable and source's alpha mask)?

I tried Screen.DrawObject(x, y, region, int) - it does not crash, at least not the YAWRR way - rather program stops with error message "Member function not found in BrightScript Component or interface".

[squirreltown]

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]

"EnTerr" wrote:

"TheEndless" wrote:

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

It does.

So it must be there to stay and it's about time they document that parameter. Too many things to ask w/o doc
- What kind of value has to be passed? It did not seem to be 1 octet only for Alpha. Is it RGBA and if so what's the role of RGB there.
- Do all the other alphas get ignored when that param is present (i.e. destination's alphaEnable and source's alpha mask)?

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).

"EnTerr" wrote:
I tried Screen.DrawObject(x, y, region, int) - it does not crash, at least not the YAWRR way - rather program stops with error message "Member function not found in BrightScript Component or interface".

That's what I meant by crash... a channel crash, not a full system meltdown.

[squirreltown]

"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.