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).
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).
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?
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… ?
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.
“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…
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.
“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.
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.
“jbrave” wrote:
Wow! Works fast enough on my Roku HD, although for the first 20 seconds it was sluggish.
Interesting. The fake 3D perspective is cheated from a bunch of still images of different areas of the screen, and it sounds like you’ve cached most of them after about 20 seconds. But on my box (an original model), it never gets out of “sluggish” mode. Do you have one of the newer models? I’m wondering if they either have more RAM, or handle it differently.
Would you be willing to reboot into 4:3 mode, and see how the speed compares?
“jbrave” wrote:
One more thing: have your app load the images off the net, so you don’t have to worry about 500k app limit.
I’m not a big fan of doing this. Depending upon how many people play the game, I could find myself either paying for the bandwidth costs myself, or dependent on the reliability of a third-party free hosting site. Keeping everything local is the most permanent, reliable option.
“NanoZim” wrote:
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…
The 500kb limit is a recommendation. The enforced limit is 2mb.
“jbrave” wrote:
One more thing: have your app load the images off the net, so you don’t have to worry about 500k app limit.
I’m not a big fan of doing this. Depending upon how many people play the game, I could find myself either paying for the bandwidth costs myself, or dependent on the reliability of a third-party free hosting site. Keeping everything local is the most permanent, reliable option.
If 2MB is not enough, perhaps allowing the extra images to be installed on a local server.
Specifically, in the “advanced mode” you could allow lots of extra images and or code to
be downloaded by the user once and put on NAS device or local web server.
That would accomplish several things. First, you only have to supply the original download
and updates. Second, all the bandwidth for the user would be LAN based, (100Mbps
Ethernet or Wifi). Third, no real limit on the size, levels or complexity. That could make
this a very interesting experience.
If you do go this route, I would have 2 modes. The first that’s all included so that new
users would have a straight forward install for demonstation purposes.
Although I’ve had no confirmation of this but it seems that Roku has Implemented a fix to the channel limit. One or Two of the Channels on my Roku seem to Load before Launching. This could mean they decided to use the method of Keeping lesser used Channels stored off the Roku until the user decides to use them, the Roku then Downloads the necessary files from the Server. Please correct me if I’m wrong. Just thought this little Info could be of use.
The Channel I keep getting this Loading Thing on is CDNTwo. If you guys also get it only on CDNTwo then I guess something else is Going on.
In v2.8, we have changed the way we load the channels… Not all the channels need to be loaded at all times, like in prior versions.
However, we are still enforcing a less than 500k warning (and recommendation to keep under this limit to be a good citizen on the box) and a strict less than 2MB limit where we won’t even load your channel.
“RokuKevin” wrote:
In v2.8, we have changed the way we load the channels… Not all the channels need to be loaded at all times, like in prior versions.
However, we are still enforcing a less than 500k warning (and recommendation to keep under this limit to be a good citizen on the box) and a strict less than 2MB limit where we won’t even load your channel.
“RokuKevin” wrote:
In v2.8, we have changed the way we load the channels… Not all the channels need to be loaded at all times, like in prior versions.
…
–Kevin
Is their going to be a way to make a channel sticky?
Specifically I would like the local media channels to be
present at all times. Thus if my broadband goes down
I can still play local music, videos and see pictures.
In my case this would be the USB media and Roksbox
channels. But others do exist.
Ideally, to prevent abuse by channel writers, I would
make it so that users would have to go into the
“Settings” page and select which channels to make
sticky.
“sticky” or pre-loaded channels will not be under the developer’s control. The box will always be able to download channels that aren’t initially loaded at boot time. If your channel becomes one of the user’s most used channels it will become one of the pre-loaded channels.
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).
