Roku Developer Program

[BradC]

I believe that was it Mark. Should be irrelevant here if using the method suggested by the Endless.

[EnTerr]

"Romans_I_XVI" wrote:
Do you have a suggestion/example of how to go about switching the sprite movement to time based instead of frame based? I would appreciate it very much. I am kinda excited now, because if I fix this I think it will actually run very smooth.

Actually you don't need any of these "easing"/tweening functions, using them in your game will be backwards - they will work well when you know you want to move an object from point A to point B with certain dynamic behavior. In your game though (warning - haven't tried it but i think i glanced youtube video of yours) is much more likely you are simulating physics, so if an object was at position (x,y) and moves with constant speed vector (Vx, Vy), then after certain amount of time dt, the new positions would be

x_new = x + Vx * dt
y_new = y + Vy * dt

Trivial, right? Now when we add acceleration (Ax, Ay) - say caused by force of jet engine, we'll need to update the velocity in the same way (it doesn't matter if that is done before or after position update but should be done consistently):

Vx_new = Vx + Ax * dt
Vy_new = Vy + Ay * dt

And you do that before every redraw/every frame (could less or more often but let's keep it simple). Ok but how much is dt (time delta)? Quite simply, the difference between the time of previous frame and the current one:

newTime = tmr.totalMilliseconds()
dt = newTime - oldTime
oldTime =  newTime

And all that is left is to decide on what the object speeds/accelerations will be - in pixels/ms. But i assume you already have most of this done, except in pixels/frame. So convert them by dividing by how many milliseconds/frame based on your "golden standard" of player you tuned it for. E.g. assuming you got 30fps (if using double-buffered roScreen, average fps will be either 30fps or 60fps because of effect of Vsync), that's 33ms/frame. Say object's speed was 33 pixels/frame, divided by 33 ms/frame = 1 pixels/ms. And now when using deltaT on redraw, if still having 30fps, the time elapsed since previous frame will be 1000 ms / 30 ~= 33 ms, x 1 px/ms = 33 pixels, like before! But say you are on slow/old player and it only can crank about 15 fps, well then time since previous frame will be 67 ms, x 1 = 67 px - so the object will move 67 px per frame but since there are only 15 frames/sec, it will travel the same distance per second on both players (1000px/sec) and game dynamics will be the same. Except on faster player it will run "smoother", on really slow may seem chunkier/jumpy - but as responsive. If you think about it some more, maybe you'd agree the frame-based kinematics was actually a complication, compared to a time-based one.

So practically speaking, there is precious little to do to upgrade it to time-based movement - just replace pixel/frame speeds with pixel/ms and measure time from previous frame (single timer is enough) and you are GTG

[Romans_I_XVI]

Thanks EnTerr for the additional suggestion. I'm not sure if there are any differences in the behavior/performance between what you suggested and the easing function, but I've already implemented the easing function throughout my entire game now so I'm just going to leave it as is. I would be interested if anybody has thoughts on these two methods for moving sprites based on time. It wasn't that hard for me to add the easing function but what was difficult was getting the pause to work properly and also the part where the enemy stops at the top of the screen unless another script is run then it exits the screen. Aside from that all the behavior in my game is essentially just - start at this position, move to that position, and then destroy yourself if nothing killed you in the mean time 🙂 .

I think I'm done now. But my brain is fried. I thought I was done with my game until this madness.

I am still not happy with how the Roku grabs key presses. I figured out the way the Roku knows if the remote sent a "button released" event is because it is no longer receiving the "button pressed" signal. Go ahead and try it, take your Roku 1 (or any Roku with a IR remote) and hold any button down. You will see the little light on the front of your Roku flickering. If you point the remote away from the Roku so the signal doesn't reach it, you will receive a "button released" event. 3 out of 4 actions in my game involve holding down a button, and whatever data the Roku is receiving when a button is held down causes it the fps to drop out like crazy! My Roku 3 is fast enough it's doesn't have any effect, but the Roku 1 is just not powerful enough for this remote signal processing business, everything else runs smooth though. Something to keep in mind when developing.

[EnTerr]

"Romans_I_XVI" wrote:
I would be interested if anybody has thoughts on these two methods for moving sprites based on time. ... the behavior in my game is essentially just - start at this position, move to that position, and then destroy yourself if nothing killed you in the mean time 🙂 .

Ah ok... then maybe "easing" objects is for you. The difference is not big and in particular if you use linear easing, you'll get the same result as in a "proper" simulation with simple mechanics (fixed speed).

Let me explain a little more, so it does not seem i thrashed the use of easing functions in general. I am not - they are quite useful when you know you want an image moved from point A to point B and want to fake a "natural" movement. E.g. one may use say cubic function when wanting object movement to start slowly, speed up significantly and then slow down when reaching the destination. So it looks as if a human picks up the object, moves it and then lays it down. Or a car starts, drives and stops at destination. Lots of natural processes like that. But then there are also other functions - say you want to add some oscillation at the end - e.g. speedometer gauge and you want the dial pointer to vibrate a little after jumping suddenly to a new value. That can also be done by picking a good fn and no need to understand the mechanics of what causes that behavior in real life.

And there are other cases where easing function cannot help you. Say you are doing something like a "lunar lander" sort of game. You know where ship is now, point A - but don't know where is point B - that's all determined by its current speed and acceleration, caused by gravitation and the engine. And easing formula cannot be used. That's when you' have to use the kinematics formulas above - for a "proper" simulation - and time quantization will show a "natural" behavior too. That's why i said it will be "backwards" introducing easing functions if you already had kinematic simulation in place.

[Romans_I_XVI]

Thanks for the explanation. This is all good knowledge to have for future game development. Now it seems the only places I get fps drop is when I hold down a button, when the music loop restarts, and sometimes when triggering a roAudioResource() sound. If anyone has any tips on this stuff I'm all ears. I think I'm going to duplicate the background music 5 times in 1 file so it doesn't restart so often, approx. every 2:30 now instead of every 0:30 seconds.