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
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 crossfadesWhat 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:
[upload|d6rJ9jFDt4nNZEbOOEQGeg==]
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.
Thats cool. I should have said external (.png .jpg) bitmaps.
“EnTerr” wrote:
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.
Assuming you’ve pasted that code directly into Main/RunUserInterface, it’s likely because you don’t have a facade open to keep the channel alive, and the call to CreateObject(“roBitmap”) is right on the edge of the threshold. Move the CreateObject(“roScreen”) before the creation of the bitmap, and I bet it runs 100% of the time.
It ran 3 times in a row on my 2XS, but i moved the roscreen like Endless suggested.
“TheEndless” wrote:
“EnTerr” wrote:
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.
Assuming you’ve pasted that code directly into Main/RunUserInterface, it’s likely because you don’t have a facade open to keep the channel alive, and the call to CreateObject(“roBitmap”) is right on the edge of the threshold. Move the CreateObject(“roScreen”) before the creation of the bitmap, and I bet it runs 100% of the time.
Yes, code is straight from Main.
Nope, moving roScreen creation on top does not change the situation, still no good 5 out of 10 runs; no regular pattern (i.e. not every other time).
“Facade” use was prescribed to avoid channel exiting prematurely - but this is not the case here, it happily stays in “wait”. I can ctrl-C that in console and code gets interrupted. Then the usual YMMV “sudden death syndrome” may happen (i.e. Roku exit to main menu) - but if it stays - i can issue commands like screen.finish()/swapbuffers() but the “Loading…” screen persists.
Zie Stick is on 5.4.2525…
PS. Discussion of this moved to separate thread, viewtopic.php?f=34&t=69015
“EnTerr” wrote:
“TheEndless” wrote:
“EnTerr” wrote:
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.
Assuming you’ve pasted that code directly into Main/RunUserInterface, it’s likely because you don’t have a facade open to keep the channel alive, and the call to CreateObject(“roBitmap”) is right on the edge of the threshold. Move the CreateObject(“roScreen”) before the creation of the bitmap, and I bet it runs 100% of the time.
Yes, code is straight from Main.
Nope, moving roScreen creation on top does not change the situation, still 5 out of 10 runs no good; no regular patern (i.e. not every other time).
“Facade” use was prescribed to avoid channel exiting prematurely - but this is not the case here, it stays in “wait”, i can ctrl-C that in console and code gets interrupted. Then the usual YMMV “sudden death syndrome” may happen (i.e. Roku exit to main menu) but if it stays - i can issue commands like screen.finish()/swapbuffers() but the “Loading…” screen stays.Zie Stick is on 5.4.2525…
Oh, all right.. I’ll give it a try… sheesh… brb.
EDIT: Ok, I reproduced it. My next guess was going to be that the problem was that you are passing screen.GetPort() to wait, but you never actually assign a port to screen, but that doesn’t seem to make a difference either.
If you change it to a double-buffered screen, and call SwapBuffers() instead of Finish(), it works every time. My guess is that the loading screen is double-buffered, and when you create a single buffered screen, sometimes it incorrectly shows the old back buffer that the splash screen still lives in (the race condition you referred to).
“squirreltown” wrote:
Thats cool. I should have said external (.png .jpg) bitmaps.
It works with bitmaps from files too (why wouldn’t it - a roBitmap is a roBitmap):
[upload|zBOrXYvbfoKSCASYvcE2Fw==]
ps. i call this art installation “Stairways to purple”
[spoiler=gory details:4ytc4snt]
screen = CreateObject("roScreen")
screen.Clear(&h715883ff)
screen.setAlphaEnable(true)
xfer = createObject("roUrlTransfer")
xfer.setUrl("http://www.roku.com/sites/all/themes/roku/images/logo.png")
? "get to file", xfer.getToFile("tmp:/logo.png")
bitmap = CreateObject("roBitmap", "tmp:/logo.png")
screen.drawObject(300, 300, bitmap)
screen.drawObject(50, 50+512, bitmap, &hFF)
for i = 15 to 255 step 24
screen.drawObject(50 + 0, 50 + 512-2*i, bitmap, RGBA(i, 0, 0, 255))
screen.drawObject(50 + 2*i, 50 + 512, bitmap, RGBA(0, 0, i, 255))
end for
for i = 15 to 255 step 24
screen.drawObject(50 + 2*i, 50 + 0, bitmap, RGBA(255, 0, i, 255))
screen.drawObject(50 + 512, 50 +512-2*i, bitmap, RGBA(i, 0, 255, 255))
end for
screen.finish()
wait(0, screen.getPort())
[/spoiler:4ytc4snt]
If anyone is interested I built a Roku photo slideshow app with a slide transition.
It pulls the images from a JSON feed and loads them into an array of temporary images. Then it loops through animating them all.
https://github.com/decadeofdefeat/roku-animated-slideshow
Hope this helps someone.
