Roku Developer Program

[EnTerr]

So there is a new function in ifDraw2D town:

DrawPoint(x as Integer, y as Integer, size as Float, rgba as Integer) as Void
Draws a point at (x,y) with the given size and RGBA color.

The explanation line pretty much repeats what i know from the method signature (not helpful). Roku*, can you please expand on:

• Will the point* be of square or circular nature, given a `size`?


• If "big" points are squares, how's this different from using DrawRect()?


• What is `size` - is it radius or square side?


• Why is `size` a float when (x,y) are int (i suspect there is a practical reason)


• Is (x,y) the center, upper-left or lower-left corner of the "point"?

(*) obviously, a "point" won't be a mathematical, 0-dimensional object (think infinitely small) for it will be invisible - but rather will map to a pixel or a few pixels.

[Komag]

Did you try it?

- It's a square
- It's center is at the x,y given
- different from rectangle probably because it's always a square (don't have to provide width and height, just one number), and more importantly, the coordinates are for the center, not the upper left corner
- size is the full width (or height), not radius.
- no idea why size is a float, maybe just to be more flexible for feeding it variables which might get calculated as floats in common practice.

[EnTerr]

"Komag" wrote:
Did you try it?

Try it i did not.
That's not how API documentation works, try-and-trust-it-stays-that-way is the wrong thing to do. I hope they document the intended behavior.
Thanks for checking and reporting.

Ugh! So it seems it's a mighty useless thing, basically doing this (pseudocode, since can't really implement interface method in B/S):

function ifDraw2D.drawPoint(x, y, size, rgba):
   m.drawRect(x - size/2, y - size/2, size, size, rgba)
end

[RokuJoel]

Not useless if it is faster than DrawRect. (worth testing though to see how fast/slow). Have you seen the StarField Screensaver (created by the engineer who implemented DrawPoint, and most of the other 2D API stuff).

- Joel

[EnTerr]

"RokuJoel" wrote:
Not useless if it is faster than DrawRect. (worth testing though to see how fast/slow). Have you seen the StarField Screensaver

I haven't, i presume you mean this one https://www.roku.com/channels#!details/59305/starfield
It's asking for $2 upfront, has a 1-line description and shows a single snapshot of a black screen sprinkled with dots - mighty unconvincing. A developer-2-developer advice: it should do more to woo me. Write detailed description, more photos please; if the fun is in the animation - include a video (can there be a video actually? i might be mixing with iOS and Amazon AppStore)

I actually made something like that last year in BrightScript, using only DrawRect(). It was Conway's Game of Life and it was plenty fast, multiple generations per second with zoom in and out. I was quite proud of myself for the high performance gens algorithm. Haven't shared it because i figure there are like 1 or 2 people here that have heard what Conway's Life is about. Anybody care about it? - if so i may try to find where it's gathering dust.

(created by the engineer who implemented DrawPoint, and most of the other 2D API stuff).

Well can't Mirko or RokuKC just shed some light on what's the deal-i/o with DrawPoint, instead of us reverse-engineering?
Even better to put a line or two on that in the API doc.
We are not in a tug-of-war i hope 🙂

[RokuMarkn]

Interesting .. I wrote a Life game several years ago using the NDK, so the inner loops are all compiled C code. It probably only runs on the Roku 3 though. It would be interesting to compare performance. Mine is probably close to as fast as possible using the CPU, but it would probably be much faster using OpenGL pixel shaders (ideas here and here and here among other easily googleable sites. Of course you couldn't do that on the Roku without the NDK.

--Mark

[EnTerr]

"RokuMarkn" wrote:
Interesting .. I wrote a Life game several years ago using the NDK, so the inner loops are all compiled C code. It probably only runs on the Roku 3 though. It would be interesting to compare performance. Mine is probably close to as fast as possible using the CPU, but it would probably be much faster using OpenGL pixel shaders (ideas here and here and here among other easily googleable sites. Of course you couldn't do that on the Roku without the NDK.

Ah, another unpublished "Life"!
How advanced algorithm did you use? I did *not* use hashlife, which seemed to me like insane complication (with its hyperspeed / time jumps) and therefore am much slower. But if you used a naive bitmap approach for the board in C, i can still hope to beat that with B/S code, esp. for big boards. Do you have an idea how long does it take to do say 1000 generations from r-pentomino?

[RokuJoel]

"EnTerr" wrote:
It's asking for $2 upfront, has a 1-line description and shows a single snapshot of a black screen sprinkled with dots - mighty unconvincing

If you ever ran the Starfield screensaver that came with Microsoft Windows then this is for you, and you probably don't need a better explanation.

- Joel

[RokuMarkn]

Oh you got fancy. No I just used a simple bitmap loop. At the time I wrote it I was more interested in testing the frame buffer than writing a good Life game. On a Roku 3 1000 generations of R pentomino takes 43 seconds in my game. This is on a 400 x 240 board, although the board size may not matter for you if you used a more advanced algorithm.

--Mark

[EnTerr]

"RokuMarkn" wrote:
Oh you got fancy. No I just used a simple bitmap loop. At the time I wrote it I was more interested in testing the frame buffer than writing a good Life game. On a Roku 3 1000 generations of R pentomino takes 43 seconds in my game. This is on a 400 x 240 board, although the board size may not matter for you if you used a more advanced algorithm.

Nothing too radical - i found the source and it's about 200 lines BrSc (that includes some remote control like pan and zoom* but no editor). I had to get clever, since going over ~100,000 cells (from e.g. 400x240) on each generation was not going to fly in B/S.

I tested and here is what i get, 1000x @ R-pent.: 21 sec on Roku 3 (woo-hoo!), 52 sec on RokuTV, 65 sec on 2XS. The roScreen drawing takes ~20% of the time, ~80% for the calculations for the #3100 and #4200. On a #5xxx, things differ - 24 sec drawing + 28 sec math, so it seems its graphics is 2x slower than #3xxx but the CPU is 2x faster (that's a convenient "rule of thumb", no?).

Your board - what happens at the edges, is it a "black hole" outside the board or does it wrap-around ("toroidal world")? For the R-pentomino case on a small board i think better is to be open edges since there are gliders flying away at 3 of the diagonals and if they re-enter, probably wreak havoc at the "main structure". In my case i was able to follow the 117 live cells for over 100,000 generations - though admittedly, there is very little fun in that (gliders be flying, expanding the universe, yawn).

(*) that is kind of neat, i am contemplating recording video maybe if i can figure a convenient way of recording other than holding my phone against the TV.