Roku Developer Program

[brandon15811]

Woah. I love the new External Control API. Is the Netflix channel going to have parameters?

[GandK-Geoff]

"retrotom" wrote:
Playing with individual pixels would be nice. The Roku doesn't really appear to be built for gaming -- but I wrote a [Super]Chip-8 emulator a while back that I think the Roku could handle. Only issue is drawing to the freaking screen -- unless you made each pixel an individual layer -- which would probably suck.

You don't need to go quite that far -- and yes, it would *definitely* suck. While researching shape-drawing methods for KidPaint, I tried doing a scan line polygon renderer with each horizontal span being either a layer by itself or an element on a big shared layer, and either way, it was REALLY slow. I can only imagine how slow it would have been to do it pixel-by-pixel. Thankfully, we discovered a different method of solving our problem -- binary editing the palette of pre-made shape images -- which is (shameless plug) open sourced as part of libRokuDev (http://github.com/rokudev/librokudev).

For the more general problem, we've researched binary editing the image data blocks in a PNG, and implementing a "real" 2D canvas from the ground up, but we'd rather avoid that if we can. Which is why we're hoping Roku provides an optimized component similar to an HTML5 canvas or an SDL surface. (Yes, I know they are very different. We could make either one work for our needs.) Or really go for broke and give us OpenGL ES. (I'm not picky about version, I'll take what I can get. 🙂 )

Anyone know if the low-level hardware can accelerate OpenGL ES? Or would Roku have to use a software renderer such as Mesa? Either way, I think I'd be in heaven.

[kbenson]

"GandK-Geoff" wrote:
Thankfully, we discovered a different method of solving our problem -- binary editing the palette of pre-made shape images -- which is (shameless plug) open sourced as part of libRokuDev (http://github.com/rokudev/librokudev).

Actually, a few weeks ago I was revisiting this idea, and determined that I believe I could indeed make a pixel level canvas, and even one with a near constant (and comparably short) time to update.

The trick is that PNG data sections require deflate compression, but there's nothing to say that the deflate compressed data has to actually do lots of encoding. At it's simplest level with the least compression, it's basically plain content with a few deflate header bits thrown in. Since we've already done a lot of work rewriting PNG palette and transparency header values, and have utilities to identify and rewrite portions of a PNG file, writing a new iDAT section would be trivial. We can just write individual pixels in a PNG file, and then display the file.

Yes, it's a crazy ugly hack. But if you really want a pixel level canvas that doesn't take multiple seconds to set a single pixel (which is DOES when you start putting a lot of items on the screen), this would work. I haven't bothered because I'm convinced Roku has something better in store, and have more immediate things to code on...

Anyone know if the low-level hardware can accelerate OpenGL ES? Or would Roku have to use a software renderer such as Mesa? Either way, I think I'd be in heaven.

If the hardware specs I found for I thought corresponded to the old hardware are correct, it mentioned 2D acceleration but nothing about 3D. Don't know about current hardware, but it would be a cool addition. I'm sure if we all make enough games for the platform we can influence future hardware designs... 😉

[renojim]

I did something similar with GIFs, but I was creating a whole image from scratch not changing individual pixels. It used a lot of file I/O, so I don't know if that had anything to do with its sluggishness. Anyway, it was pretty slow and went from taking ~800ms to 2800ms with one of the firmware "upgrades". I never heard back from Roku as to what the problem was. Changing individual pixels may be faster, but my image was so small to start with (something like 130x33) that I don't think I'll be doing too many experiments in this area.

-JT

[kbenson]

"renojim" wrote:
I did something similar with GIFs, but I was creating a whole image from scratch not changing individual pixels. It used a lot of file I/O, so I don't know if that had anything to do with its sluggishness. Anyway, it was pretty slow and went from taking ~800ms to 2800ms with one of the firmware "upgrades". I never heard back from Roku as to what the problem was. Changing individual pixels may be faster, but my image was so small to start with (something like 130x33) that I don't think I'll be doing too many experiments in this area.

-JT

Hmm, I don't remember exactly, but I believe we are copying a PNG to a new file, loading it into a byte array, locating the pLTE header, toggling a few bits to set the color and then writing to a file in well under 100ms. There was a bit of optimization going into shift operations on byte arrays, and fast CRC calculation.

[renojim]

I don't know if my experience is entirely relevant because all of the file I/O, but it was certainly discouraging. All I was trying to do was create a time display out of GIFs of the individual digits, so I had the digits as raw data and just had to read the data line by line (33 lines) to create a new GIF of the whole time (i.e., for the time 12:43:45 I would read the first line from the "1" data, then the first line from the "2" data, etc., and concatenate the lines together). I couldn't believe how slow it was and really couldn't believe how much slower it got, but just changing a small percentage of a GIF or PNG might not be so bad. I just know my experience soured me on the whole idea of trying to do anything too dramatic.

-JT

[kbenson]

Yeah, Geoff and I were talking about ByteArray manipulation today, in regard to hopefully some future 3D capabilities from Roku. Some language features to facilitate ByteArray manipulation would be a must if that starts becoming more common on the platform. Just the ability to do a copy of a ByteArray from point x to point y, or a copy of ByteArray A into ByteArray B starting at point x for y bytes, stuff like that. If supported through C/C++ as interface methods it should be quite fast. Those features could also be useful if they give us an animation component at some point.

[renojim]

I agree, it would have been nice to have. That's why I was using file I/O - you can select a byte range of a file. I tried writing my own memcopy type routines, but they turned out to be slower than the file I/O.

I guess we've gotten quite a bit off-topic.

-JT

[kbenson]

"renojim" wrote:
I agree, it would have been nice to have. That's why I was using file I/O - you can select a byte range of a file. I tried writing my own memcopy type routines, but they turned out to be slower than the file I/O.

Heh, I was just wondering about using toHexString and fromHexString and using substring methods...

I guess we've gotten quite a bit off-topic. :lol:

Yes, but those are the fun conversations, aren't they? 😉

[brandon15811]

"RokuKevin" wrote:
They should still be available for at least a couple more firmware releases... Any new development should be using the External Control API though.

--Kevin

Is the command for "Rewind" supposed to be spelled "Rev"? Thats how its spelled in the ECP guide