Roku Developer Program

[coolbits]

Hi,
Let's say I have a roCompositor with 10 roSprites. They are arranged as 5 columns and 2 rows. I want to move all of them to left 100px when I press the right remote key. I want them to animate (instead of change positions). What is the best method for this.

Please find the current solution I am thinking.

Psudocode:

for x =>  1 to 10
    move each sprite's x value -10px
    swapbuffer

but I don't it is the best way for several reasons.
1. I want to apply an easing function. Meantime I want all sprites to be -100px left exactly.
2. It will take some time for roku to update all sprites, so it will not show a seamless animation.

Your comments on this are much appreciated.

Thank you,
Chandana

[RokuJoel]

1. Here's an Easing function (Robert Penner easing):

function inoutquart(t as float,b as float,c as float,d as float) as float
                't=time, b=startvalue, c=change in value, d=duration
                d=d/2
                t=t/d
                if (t < 1) then return c/2*t*t*t*t + b
                     t=t-2
                return -c/2 * (t*t*t*t - 2) + b
end function

Heres a snippet of code that calls this function, including some clamping to prevent out-of-bounds issues, this code would be part of a while loop that listens for keypresses, and resets an roTimeSpan timer whenever it hears one.

time=timer.totalmilliseconds()
for i=0 to sparray.count() -1
     start=startarray[i]
     dest=destarray[i]
     chng=destarray[i]-startarray[i]
     startarray[i]=inoutquart(time,start,chng,duration)
     if time > duration then startarray[i]=destarray[i] ‘clamping to prevent out of bound values
     sprarray[i].moveto(int(startarray[i]),yposition)
end for

2. 10 sprites should be fast enough for seamless animation, especially for what you are talking about, I would expect you to be able to move a lot more than that if your program is written efficiently.

- Joel

[NewManLiving]

Make sure you use double buffering. Also make use of easing regions as opposed
To easing individual bitmaps. For example you can write a series of bitmaps to
A container bitmap making one larger bitmap and simply ease a region over 1 or more in
the combined bitmap. Also use a compositor for additional speed

[agmark]

Sounds like we have a need for a new roScreen example channel(s) for those of us interested in learning more about exploiting this screen. I've dabbled with the roScreen but much is still foreign. I think a few more working examples would be helpful.

[NewManLiving]

After reading your post, I think I can offer some help. I am new to ROKU development so I am currently working on my first application. Having mostly built it using the standard components and then rewriting a portion of it using imageCanvas, I decided to rewrite it entirely using the 2d api. As you know, this is not well documented and you basically have to discover it for yourself. Anyway lets start with the easing functions:

The time and duration values in the easing functions should not be taken literally as time of day but rather length or duration. This is more easily expressed as frames
for our purpose. It does not matter what you use (time or frames), but it must be the same 'type' for each parameter of the easing equation. I use frames; increasing the number of frames increases the duration or time it takes to ease from one point to another; and obviously the opposite is true as well. In the following code I am
moving in the x direction form x = 100 to x = 800 and I want to have a duration or time of 30 frames. To go back you simply negate newX. Just change the y direction
the same way if you are moving in the y direction. If you use are using offsets such as you would to move a region, then just subtract the difference from the previous
newX ( you would have to save the value of course)

     ' In this example we are moving the x position it would be the same for y you just move in the y direction instead of x

      curr_time   = 0             ' START TIME OR FRAME IS USUALLY 0 OR 1 DEPENDING ON YOUR FLAVOR
      start_val    = 100          ' START X OR Y POSITION DEPNDING ON MOVEMENT DIRECTION (CURRENT X POS OF YOUR SPRITE)
      change_val  = 800        ' WHERE WE ARE MOVING TO FROM START_VAL THIS WOULD BE X OR Y AS MENTIONED IN PREV LINE
      duration      = 30         ' HOW LONG SHOULD IT TAKE TO EASE THERE.  To go back just use a negative ( -newX)
           
            for i = 0 to duration 
               newX = CubeEaseOut(curr_time + i, start_val, change_val, duration)
            
            end for

]Function CubeEaseOut(t_from_frame As Float, d_to_frame As Float, b_from_xory As Float, c_to_xory As Float) As Integer

   l_ff!  = t_from_frame / d_to_frame
   l_ff!  = l_ff! - 1.0
   l_val! = c_to_xory *(l_ff! * l_ff! * l_ff! + 1.0) + b_from_xory
   l_ret% = int(l_val!)
   
   return l_ret%
 
End Function

As you can see I have changed the names to better reflect what we are trying to do: we are going to ease horizontally or vertically: from xory (b_from_xory) to xory
( c_to_xory ) , and we want the duration to be from frame (t_from_frame) to (d_to_frame). So for 20 frames it would be for i = 1 to 20.

[coolbits]

Thank you all for the help!!! Better if we have these information well documented in the official documentation.
Cheers,
Chandana

[EnTerr]

"RokuJoel" wrote:
1. Here's an Easing function (Robert Penner easing):

function inoutquart(t as float,b as float,c as float,d as float) as float
...

I looked at original J/S code and this Robert Penner guy seems to turn both math and coding into undue pain and suffering - or maybe he needed to pad the hell out of whatever book he was writing (i skimmed the "Tweening chapter of my book"). Here i re-wrote the moving function into something more comprehensible (to me it is):

function ease_in_out(done_ratio as float) as float
    'given run done_ratio=[0,1], return rise [0,1]; 'using acceleration for <0.5 and deceleration after
    t = 2 * done_ratio - 1    'convert and limit to [-1, 1]
    if t < -1 then t = -1
    if t > 1 then t = 1
    return 0.5 * (1 +  t^3)
end function

 'and then use it, no need for after-"clamping"
    ...
    startarray[i] = start + chng * ease_in_out(time / duration)

To increase the acceleration/deceleration, change t^3 to t^5 (or a higher odd power) - and if changed to simply t, the movement will be linear (at constant speed).

Where does this name "easing function" come from, can someone tell me? Is it related to "easel", the stand used to prop a painting?

[RokuJoel]

Hi @NewManLiving, question for you:

The time and duration values in the easing functions should not be taken literally as time of day but rather length or duration. This is more easily expressed as frames

Seems to me this would not work without being anchored to the actual real world time in milliseconds, otherwise the whole easing might complete in less than one frame, and thus it wouldn't ease, it would jump. Am I missing something there?

- Joel

[EnTerr]

"RokuJoel" wrote:

"NewManLiving" wrote:
The time and duration values in the easing functions should not be taken literally as time of day but rather length or duration. This is more easily expressed as frames

Seems to me this would not work without being anchored to the actual real world time in milliseconds, otherwise the whole easing might complete in less than one frame, and thus it wouldn't ease, it would jump. Am I missing something there?

I think he talks about logical frames whereas you are thinking of physical frames. I don't even know the right terminology but you seem to refer of the 60fps refresh rate of the video signal generator - whereas generation of the sequence of images (i call here "logical frames") is separate thing - and most often i would think linked to some physical timer and having in mind not to shove more than 1 image per physical refresh (because as you said, it won't be animation in everything happens within one refresh cycle). I think the point at large was that the progress meter is unit-less - it could be so-and-so ms or so-and-so logical frames (if they are happening with reasonable regularity). Note in the fn re-write how the "done_ratio" parameter is unitless, just a ratio from 0 to 1 (i.e. 0-100%); 0.2 could be "200/1000, 200ms out of 1000ms" or "10/50, frame 10 out of 50 frames".

How much is the refresh rate of Roku though? I cannot pull that from the docs, maybe it was considered so fundamental, so obvious nobody wrote it down? Before in TV there was the whole gallimaufry about NTSC 60 (North America) vs PAL/SECAM 50 (the World) etc. All i seem to get is about 23.976 fps or 29.97 fps - which is about video formats.

[NewManLiving]

I have posted enough code that uses easing.
My grids and lists employ simple easing and
are adapted from penner
And others who have modified penners formulas The one
I use most often is the most basic, but I do use others
But the technique that I use has already been
Demonstrated