Roku Developer Program

[NanoZim]

Is it possible to change the Roku's resolution from within BrightScript?

I'm developing a game that's pretty graphics intensive. My Roku is hooked up to an HD TV set. When I manually change the box to 4:3, reboot, and push my graphics out at 640x360, the game runs beautifully. However, when I leave the box at 720p and scale my graphics up to 1280x720, the game runs pretty slow. And pushing the graphics out at 640x360 while in HD mode obviously creates a game-in-a-tiny-box experience.

So ideally, I want HD users to be able to just click on the game and get full-screen great performance, without having to reboot their boxes first. Which means allowing the game to change the resolution down to SD (and doing so without rebooting).

Is this possible?

[kbenson]

As far as I'm aware, currently the Roku has to restart to choose a different video type (SD/HD720/HD1080). Maybe later there will be a way in some components to cause it to fall back to a lower resolution, but I doubt that will ever be the case for the roImageCanvas component. The canvas is meant just for graphic display and video overlay, not necessarily for complex interaction of multiple components in a responsive manner. I'm sure Roku has seen the need for something that allows finer grain control, hopefully there will be something soon (this goes similarly for audio, using roAudioPlayer for sound effects are extremely unreliable currently).

[NanoZim]

While you may be right, I'm hoping you're not. :shock:

To see the performance discrepancy, you need an HD set. I put my work-in-progress game here:
https://owner.roku.com/Account/ChannelCode/?code=N0RDJ

Set your display type to "4:3 standard", let the box reboot, and then launch the game. Run around the perimeter of the map to get a feel for how quickly it runs.

Now set your display to "HDTV 720p", reboot, and launch it again. You'll see how horrendous the gameplay difference is. It's because it stretches the X & Y axes by a factor of two, effectively drawing 4 times as much artwork as before. At 4:3, it's easy to imagine running around and facing off against an enemy. At 720p, it would be basically impossible.

Since a manual settings change provides what I need, it seems like this is a software issue, not hardware. If that's true, then maybe some of the Roku engineers will consider looking into a solution?

[TheEndless]

"NanoZim" wrote:
While you may be right, I'm hoping you're not. :shock:

To see the performance discrepancy, you need an HD set. I put my work-in-progress game here:
https://owner.roku.com/Account/ChannelCode/?code=N0RDJ

Set your display type to "4:3 standard", let the box reboot, and then launch the game. Run around the perimeter of the map to get a feel for how quickly it runs.

Now set your display to "HDTV 720p", reboot, and launch it again. You'll see how horrendous the gameplay difference is. It's because it stretches the X & Y axes by a factor of two, effectively drawing 4 times as much artwork as before. At 4:3, it's easy to imagine running around and facing off against an enemy. At 720p, it would be basically impossible.

Do a search for roImageCanvas in this forum for a couple threads that discuss the image canvas performance in depth. There are a number of things you can do to improve performance, but it's unlikely you'll ever get the same 480p performance at 720p.

"NanoZim" wrote:
Since a manual settings change provides what I need, it seems like this is a software issue, not hardware. If that's true, then maybe some of the Roku engineers will consider looking into a solution?

As you already noted, a manual settings change requires a reboot, so I'm not sure why you'd think it was software and not hardware... ?

[kbenson]

"NanoZim" wrote:

To see the performance discrepancy, you need an HD set. I put my work-in-progress game here:
https://owner.roku.com/Account/ChannelCode/?code=N0RDJ

Believe me, I'm well aware of the performance limitations of the canvas. We've had plenty of discussions here about it. 😉 There are techniques (hacks) to mitigate the problem, and you can find hints about how to use them effectively in prior threads. In short, you use multiple canvas objects. If done intelligently, I think you could probably use a separate canvas for the background image and foreground tiles. It's a little tricky because you have to re-show the background if you move something in the foreground (or it leaves the pixels changed), but if you change the way you show the selected tile, you can probably get away with just re-showing the foreground canvas every action. Even if you have to re-show the background canvas, after it's been shown once, calling .show() on it again without any changes is very quick (probably less than 20ms, but you have to test).

It's a lot of work, but it can yield somewhat better performance.

P.S. Have you tried shipping with two background images, one for SD and one for HD to see if a non-scaled HD image yields better performance? Sometimes it's little actions you don't expect to be problematic that cause the most trouble.

[NanoZim]

"TheEndless" wrote:
As you already noted, a manual settings change requires a reboot, so I'm not sure why you'd think it was software and not hardware... ?

What I'm hoping is that the long reboot is only required for something as extensive as switching the entire interface to a different resolution. But if the box only needs to switch to low-res for the duration of roImageCanvas' life, without loading new interface elements, settings, etc., then I'm hoping the change can happen much quicker, and that it can happen from software & revert back to HD once the application ends.

Point is, clearly the Roku hardware can run full-screen at an SD resolution. So my question isn't whether the hardware is capable of this; it's whether the SOFTWARE is capable of triggering it when desired. It's a question I don't have an answer to, but I'm guessing the Roku engineers do.

I don't know how interested the Roku folks are in adding games to the Content Store, but I've gathered hints (anyone else take last month's Roku User Survey?) that it's something that's at least being considered. However, Roku games need to be compatible with both SD & HD sets. And anything beyond turn-based play requires a certain level of consistency in timing between the resolutions, for gameplay balance. So if Roku IS considering making the box more game-friendly, then I would imagine this is an issue they would be keen to look into.

"kbenson" wrote:
There are techniques (hacks) to mitigate the problem, and you can find hints about how to use them effectively in prior threads. In short, you use multiple canvas objects.

I do know about this trick. And while it would be tricky for my current game, it's not entirely impossible. However, the biggest problem is that this game is first-person-perspective. So even if I can optimize some screen redraws, there are a number of times where the entire screen changes, so there will still be many key points where the entire game will slow to a crawl.

"kbenson" wrote:
Have you tried shipping with two background images, one for SD and one for HD to see if a non-scaled HD image yields better performance? Sometimes it's little actions you don't expect to be problematic that cause the most trouble.

I probably can't implement that for this current game, because I'm maxing out my 500kb file limit with the current graphics; there's no way I could include full-HD-res images. But now you've got me really curious about how much of a performance hit the rescaling causes! :? I need to do some tests...

[Arwen]

This actually would be a nice feature. It's already supported
a bit by playing 1080p videos on the XD & XD|S models, (and
later on the XR model). The user interface is 720p and any
1080p video content would play at 1080p.

Ideally this would be under BrightScript control. Simple
example. My digital camer, (1999 era), is 1280 x 960.
Thus, with 1080p I could see my European vacation,
(not as good a Chevy Chase's version :), pictures in
full resolution.

Even the camera's Hi-pict resolution is very close to
1080p, 1600 x 1200.

[TheEndless]

"NanoZim" wrote:

"kbenson" wrote:
Have you tried shipping with two background images, one for SD and one for HD to see if a non-scaled HD image yields better performance? Sometimes it's little actions you don't expect to be problematic that cause the most trouble.

I probably can't implement that for this current game, because I'm maxing out my 500kb file limit with the current graphics; there's no way I could include full-HD-res images. But now you've got me really curious about how much of a performance hit the rescaling causes! :? I need to do some tests...

You'll also see a significant performance increase if you slice your background image into multiple pieces and draw them independently. You can accomplish this with a single image by using the SourceRect attribute effectively. Doing this, I saw a performance bump in the hundreds of milliseconds.

[jbrave]

Wow! Works fast enough on my Roku HD, although for the first 20 seconds it was sluggish. I wonder if you could speed it up just by optimizing the way your loop & conditionals where you are waiting for keypresses works, thats kind of my impression from the feel of the app that this may be one of your bottlenecks.

- Joel

[jbrave]

One more thing: have your app load the images off the net, so you don't have to worry about 500k app limit.

- Joel