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.
I want to apply an easing function. Meantime I want all sprites to be -100px left exactly.
It will take some time for roku to update all sprites, so it will not show a seamless animation.
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
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.
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.
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?
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 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
“EnTerr” wrote: How much is the refresh rate of Roku though?
The max frame rate is 60 fps and is tied to the vsync of the monitor, so, in UK probably 50fps
“EnTerr” wrote: How much is the refresh rate of Roku though?
The max frame rate is 60 fps and is tied to the vsync of the monitor, so, in UK probably 50fps
Does this mean if i use roScreen with Roku in HDTV mode, i am guaranteed to get either 50Hz or 60Hz?
Any idea where i can read more on this (re Roku choosing output refresh rate)?
“EnTerr” wrote: How much is the refresh rate of Roku though?
The max frame rate is 60 fps and is tied to the vsync of the monitor, so, in UK probably 50fps
Does this mean if i use roScreen with Roku in HDTV mode, i am guaranteed to get either 50Hz or 60Hz?
Any idea where i can read more on this (re Roku choosing output refresh rate)?
It’s not entirely clear what you’re asking, but the framerate for roScreen is heavily dependent on what your code needs to do. The max you’ll get is 60 fps, but if you’re drawing a lot to the screen (particularly text), and doing other processing at the same time, then your framerate is going to suffer. It’s much easier to achieve ~60 fps on the Roku 3 than it is on the lower and older models. I believe the legacy Rokus (firmware 3.x) max out at 30 fps.
“EnTerr” wrote:
Does this mean if i use roScreen with Roku in HDTV mode, i am guaranteed to get either 50Hz or 60Hz?
Any idea where i can read more on this (re Roku choosing output refresh rate)?
It’s not entirely clear what you’re asking, but the framerate for roScreen is heavily dependent on what your code needs to do. The max you’ll get is 60 fps, but if you’re drawing a lot to the screen (particularly text), and doing other processing at the same time, then your framerate is going to suffer. It’s much easier to achieve ~60 fps on the Roku 3 than it is on the lower and older models. I believe the legacy Rokus (firmware 3.x) max out at 30 fps.
You misunderstand.
You are thinking Frame_rate#Video_games, whereas i am talking Frame_rate#Digital_video_and_television
The hardware refresh rate with which Roku outputs to HDTV is likely one of the values here: https://en.wikipedia.org/wiki/Hdtv#Stan … ield_rates - it happens at pre-determined interval, no matter how fast or slow you draw your images. Say hardware refresh rate were 30Hz (30 frames per second) and you draw at 40fps, then every 4th frame you draw does not make it on screen, giving you fine jerks in the motion.
PS. When talking about playing video, in 3 places wiki docs say that only 23.976 fps or 29.97 fps are supported, which is likely connected to the hardware refresh rate.
“EnTerr” wrote:
Does this mean if i use roScreen with Roku in HDTV mode, i am guaranteed to get either 50Hz or 60Hz?
Any idea where i can read more on this (re Roku choosing output refresh rate)?
It’s not entirely clear what you’re asking, but the framerate for roScreen is heavily dependent on what your code needs to do. The max you’ll get is 60 fps, but if you’re drawing a lot to the screen (particularly text), and doing other processing at the same time, then your framerate is going to suffer. It’s much easier to achieve ~60 fps on the Roku 3 than it is on the lower and older models. I believe the legacy Rokus (firmware 3.x) max out at 30 fps.
You misunderstand.
You are thinking Frame_rate#Video_games, whereas i am talking Frame_rate#Digital_video_and_television
There is the hardware refresh rate with which Roku outputs to HDTV, likely limited to some of the values here: https://en.wikipedia.org/wiki/Hdtv#Stan … ield_rates . When talking about playing video, in 3 places wiki docs say that only 23.976 fps or 29.97 fps are supported, which is likely relevant and connected to the hardware refresh rate.
But you asked specifically in relation to roScreen, which uses the graphics plane, not the video plane. The refresh rate of the video is completely independent of that of the roScreen (though it’s harder to achieve higher framerates with the roScreen when video is playing, presumably due to the video decoder eating up CPU cycles).
“TheEndless” wrote:
But you asked specifically in relation to roScreen, which uses the graphics plane, not the video plane. The refresh rate of the video is completely independent of that of the roScreen (though it’s harder to achieve higher framerates with the roScreen when video is playing, presumably due to the video decoder eating up CPU cycles).
They cannot be “completely independent”. At the end of the day - no matter the conceptual separation to planes - the video processor has to push a new, fully rasterized frame (say 1280×720p) over HDMI - every X ms, on the clock (somewhere in 17-42ms). And if the output video signal rate is not a multiple (1x, 2x) of the video frame rate, ugly things happen. Rate syncing is a huge PITA; e.g. if you have not encountered the term “telecine” before, look it up to see more that one would ever care to know.
ps. i said “roScreen” specifically to narrow the possibilities. I assume that to display 1080p video, Roku switches HDMI output format from 720p to 1080 - and i am not interested in 1080p since i can’t use roScreen with 1080.
“TheEndless” wrote:
But you asked specifically in relation to roScreen, which uses the graphics plane, not the video plane. The refresh rate of the video is completely independent of that of the roScreen (though it’s harder to achieve higher framerates with the roScreen when video is playing, presumably due to the video decoder eating up CPU cycles).
They cannot be “completely independent”. At the end of the day - no matter the conceptual separation to planes - the video processor has to push a new, fully rasterized frame (say 1280×720p) over HDMI - every X ms, on the clock (typically 17-42ms). And if the output video signal rate is not a multiple (1x, 2x) of the video frame rate, ugly things happen. Rate syncing is a huge PITA; e.g. if you have not encountered the term “telecine” before, look it up to see more that one would ever care to know.
The output refresh rate is always 60Hz (in the US), regardless of how long it takes you to draw a single roScreen frame.
“EnTerr” wrote:
ps. i said “roScreen” specifically to narrow the possibilities. I assume that to display 1080p video, Roku switches HDMI output format from 720p to 1080 - and i am not interested in 1080p since i can’t use roScreen with 1080.
When the Roku is set to 1080p, it always outputs at 1080p (with the exception of legacy 3.x boxes)… it upscales the graphics plane to 1080p. You can do 1080p video with a 720p roScreen, but you’re restricted considerably more on graphics memory, which can cause playback errors if you overrun it.
“TheEndless” wrote:
The output refresh rate is always 60Hz (in the US), regardless of how long it takes you to draw a single roScreen frame.How do you know that? You say it with conviction, is there a spec (radical idea) i can find? My censored Sony TV shows resolution but not Hz.
When the Roku is set to 1080p, it always outputs at 1080p (with the exception of legacy 3.x boxes)… it upscales the graphics plane to 1080p. You can do 1080p video with a 720p roScreen, but you’re restricted considerably more on graphics memory, which can cause playback errors if you overrun it.Ha, this caught me by surprise. Did not expect to be able to mix “different resolutions” beyond roScreen scaling. There is lots of buffers being used, one output frame in 1080 is likely about 8MB; doco mentions level 4 of H264, which i see allows 4 reference frames, so that’s 40MB before even considering graphics overlay and video stream buffering. This OpenGL stuff must be very good in frame buffer shaking and stirring - will have to read about that - but that will explain why 27xx models are lagging in your tests while having faster CPU - if there is no OpenGL hardware there, it has to be emulated.
“TheEndless” wrote:
The output refresh rate is always 60Hz (in the US), regardless of how long it takes you to draw a single roScreen frame.How do you know that? You say it with conviction, is there a spec (radical idea) i can find? My censored Sony TV shows resolution but not Hz.
Primarily because the video framerate isn’t affected when drawing overlays to the roScreen. If you break into the debugger, for instance, video continues to play, while the last frame of your roScreen is also displayed. But also because the monitor I use for development does display the refresh rate, and it’s always 60Hz, with or without video playing, even for the SD resolutions.
I’d have sworn they listed that online in the detailed specs on the comparison chart at one time, but I can’t find it now.
