Roku Developer Program

[bbefilms]

Hi;

I'm just getting back into developing a Roku channel after a long period of not being involved. From what I can see, there appears to be API fragmentation depending on the Roku player supported (first gen vs 2nd gen). Also, I've seen some reports that channels that work on Roku 1 won't work on a Roku 2. Someone correct me.

[RokuChris]

Newer firmwares have added new SDK features and functionality and not everything that you can do in 4.8 is possible in 3.1. You should always test any channel you develop on all the different firmwares you intend to deploy it to.

I'm not sure about channels that work on older boxes not working on Roku2. It's not something I've heard of.

[Anonymous]

As Chris mentioned above, there are some newer API's and features that are not available on the initial Roku players (Smooth Streaming for example), but we strive to be fully forward compatible.

If you find any issues with apps that work on Roku 1 players that do not work on current models, please let us know and we will investigate.

Cheers,
Jon

[destruk]

There's not much you can do about the speed variations? - meaning on roku1 roscreen drawing from tmp files is slower, and on roku2 the wait command for message ports has an enforced minimum delay of 10-15ms that roku 1 doesn't have. It would be great if both roku 1 and roku 2 could run at the same speeds for animation and games.

old thread on the roku 2 and the message port wait delays -
viewtopic.php?f=34&t=46452&hilit=goto

[RokuKevin]

If your game depends on timing, your frame rendering loop should use timers to control the frame rate.

Our simple2d sample application just renders frames as fast as it can and you do see a difference in game timing between the Roku1 and Roku2. You could add a wait() in that loop with a timeout that you calculate to be the next frame rendering time.

Of course, it's possible that the Roku1 will not be able to support the frame rates that the Roku 2 does but your timers in the render loop should keep the timing of your game the same on both platforms.

--Kevin

[TheEndless]

"RokuKevin" wrote:
If your game depends on timing, your frame rendering loop should use timers to control the frame rate.

Our simple2d sample application just renders frames as fast as it can and you do see a difference in game timing between the Roku1 and Roku2. You could add a wait() in that loop with a timeout that you calculate to be the next frame rendering time.

Of course, it's possible that the Roku1 will not be able to support the frame rates that the Roku 2 does but your timers in the render loop should keep the timing of your game the same on both platforms.

--Kevin

Kevin,
Wait() and Sleep() aren't consistent on the Roku 2 firmware, so they really can't be used for timing. See this thread for more information on that: viewtopic.php?f=34&t=46452
Hopefully that will be fixed at some point in the near future.

[RokuKevin]

I looked into the wait() inaccuracy on the Roku 2, and unfortunately we have had an open bug on this platform that affects both wait() and sleep(). Enabling the high resolution timer in these methods caused instability in the firmware so it is currently disabled. We'll have to fix these before using wait() or sleep() becomes a viable option for this use case.

In the meantime, you could use the rotimespan component to get a high resolution timer and check for events in the busy-wait loop with a call to msgport.getmessage() (which does return immediately whether there's a message or not).

--Kevin

[destruk]

all right. Thanks. With the high resolution timer going like that, screenshots take a lot longer to process, but that's the price to be paid. 🙂

[bbefilms]

Sorry, haven't been following this as I should have; thanks Chris and others for the replies.

[EnTerr]

"RokuKevin" wrote:
I looked into the wait() inaccuracy on the Roku 2, and unfortunately we have had an open bug on this platform that affects both wait() and sleep(). Enabling the high resolution timer in these methods caused instability in the firmware so it is currently disabled. We'll have to fix these before using wait() or sleep() becomes a viable option for this use case.

In the meantime, you could use the rotimespan component to get a high resolution timer and check for events in the busy-wait loop with a call to msgport.getmessage() (which does return immediately whether there's a message or not).

Has this been fixed yet? I.e. can we rely on accurate wait() and sleep()?
The linked msg was showing wait(1, port) takes at least 15ms on ARM platform (and that, as he pointed out, is 50% of time interval available per frame at 30fps)

It has been over a year and currently doco for roMessagePort.WaitMessage() and wait() and sleep() makes no qualifications, so one would imply precision and accuracy are under 1ms (i.e. you get what you ask for).

If on the other hand that was never addressed and is here to stay, can we get statement what's the resolution/granularity in those functions work and update the documentation?