Is game fps lag acceptable on slower devices?

Archived
1

I bought a Roku 1 to make sure my game looks ok in SD mode, and much to my surprise the game ran very poor on the Roku 1. I knew that Roku 3 was more powerful, but hadn’t realized how much. Well after many hours of work I have sifted through my code and made corrections to optimize the game in as many places as I possibly could. I do notice an improvement in the performance but even if I disable all extra scripts (like collision detection and such), set screen.SetAlphaEnable(false), disable all DrawText(), and remove the scrolling background, I still don’t get flawless playback. I used roTimeStamp to see what was taking the most time to process and essentially all of my scripts were 0-1 milliseconds but the screen.DrawAll() would peak at about 18-20 milliseconds when the screen was full. This tells me that there is just simply too many sprites that the Roku is trying to draw on the screen in a short amount of time.

So the main question is, is it acceptable to release the game to be available on slower devices, even if it doesn’t play at the highest fps all the time? It really reminds me of back in the day when I had an under powered desktop trying to play a higher end game. It’s not like there are glitches or unexpected lag, but if the screen is full of a lot of stuff, things slow down a bit.

To me it seems Roku 1 users would be understanding considering even the main screen runs slow at times lol.

One side note on the Roku 1, there is something strange with the RF remote, If you hold down a button (even if my game is not designed to do any action with that button, * for instance) it will cause the fps to drop. Which is unfortunate because my game involves a lot of holding down buttons.

Also if anyone has any additional tips on increasing performance I would of course be open to them.

Thanks.

2

“Romans_I_XVI” wrote:
but the screen.DrawAll() would peak at about 18-20 milliseconds when the screen was full.
I assume you either mean compositor.DrawAll() or screen.SwapBuffers().. Either way, you’ll never get faster than 60 fps when drawing to the screen, which is ~16ms. 18-20ms isn’t bad at all, especially on the lower end hardware. As long as you’re able to accomplish ~20fps (~50ms), and your animation is time based and not frame based (i.e., objects move at the same distance in the same amount of time regardless of framerate), I think you’d be fine releasing to all platforms.

“Romans_I_XVI” wrote:
If you hold down a button (even if my game is not designed to do any action with that button, * for instance) it will cause the fps to drop
I don’t know what your code looks like, but I’d take a look at your button repeat code. Are you sure you don’t have it doing anything when the button is one that you’re not concerned about? If you’re setting the button pressed flag in your code regardless of which button is pressed, perhaps you should try only setting it when the buttons you care about are pressed, so it’ll never drop into the button repeat code.

3

“TheEndless” wrote:
As long as you’re able to accomplish ~20fps (~50ms), and your animation is time based and not frame based (i.e., objects move at the same distance in the same amount of time regardless of framerate)

Wow, I am an idiot… why did this never occur to me. I have all of the sprites moving a certain distance every time it cycles through the While loop. So If I have a fps drop the whole game slows down. Instead of just dropping frames. I feel like an idiot lol. Good reminder that I am still somewhat of a newbie when it comes to development.

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.

4

“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.
I typically use a variation of one or more of Robert Penner’s easing functions: http://www.robertpenner.com/easing/
If everything moves at a constant speed, then a simple linear tween should do the trick:

Function LinearTween(start As Integer, finish As Integer, currentTime As Integer, duration As Integer) As Integer
    If currentTime > duration Then Return finish
    change = finish - start
    time = currentTime / duration
    Return change * time + start
End Function
5

I’m trying to wrap my head around how exactly this will work. Could you be more specific as to what each one of the variables needs to be. Like let’s say I just want to change the y position so many pixels depending on the time. I’m guessing start = somesprite.GetY() and finish = somesprite.GetY()+10 but what is current time and duration going to be? Or am I completely off?

Here’s a snippet of code if this helps.

Function move_enemy_1()
    removed = -1
    for each item in m.spr_enemy_1
        y = item.GetY()+m.enemy_1_speed
        item.MoveTo(item.GetX(), y)
        if y > 740
            removed = removed+1
        end if 
    end for
    if removed > -1
        for r = 0 to removed
            m.spr_enemy_1[0].Remove()
            m.spr_enemy_1.Shift()
        end for
    end if
End Function

That’s how I cycle through that enemy type and move all the sprites right now. How would I go about turning this in to a LinearTween?

6

If you wanted to move a sprite from Y position 0 to 100 over a period of 5 seconds, you’d have a timer marked at the beginning of the movement, then get the current Y position each pass through your loop by calling:

newY = LinearTween(0, 100, timer.TotalMilliseconds(), 5000)

Once newY = 100 or timer.TotalMilliseconds() > 5000, then your animation is complete. If you need to change direction in the middle of the animation, you’d set the start position to the current newY value. So basically, if you’ve decided that it takes a sprite 5 seconds to move a specific distance, then those are the values you’d pass to LinearTween. You just need to make sure your timer is restarted any time the animation (re)starts, and your start value is equal to where the sprite resides at the beginning of the animation.

As I mentioned before, I’ve modified Robert Penner’s functions to better suit how I prefer to use them. You may have better luck using a straight port. This page details how they work: http://upshots.org/actionscript/jsas-un … ing-easing

7

You are my hero!

Now I just need to rewrite my entire game… lol. Well that’s exaggerating. It works beautifully though. It took me a little bit to figure out how I would impliment it for moving each sprite down the screen and also how to handle pausing the game (since it’s now based on time I can’t just pause the script like before). Now I just need to make all in game movement based on that magic function and we are good to go. Thanks again!

8

This is all new to me as well, and I can see how useful this sort of stuff would be. I’ve opted for more the NES route though, to have some slowdown for the sake of precision. Although I’ve implemented a half-framerate version for slower Rokus and even a 1/4 framerate option just in case.

I’ll bookmark this as I may reconsider down the road. :slightly_smiling_face:

But what about what Brad C said?
“Roku 3 - timing is off, you may have to make adjustments if you rely on this.”

If I do decide to use “easing”, won’t that rely heavily on exact timing A LOT?

9

I’m guessing it’s just not exact so the gameplay might be faster or slower on the Roku 3. I haven’t got that far yet but we will see. My timing doesn’t need to be exact though so I’m guessing it will be fine.

10

Using time based animation is much superior than counting frames. Even if your redrawing code takes much less than 16 ms, occasional glitches may occur if the system gets temporarily busy doing other things. Such glitches are barely visible with time-based animation but can be quite jarring with frame based.

I don’t know what Brad was referring to, but roTimespan is very accurate on all platforms. Possibly he was referring to the fact that when wait() times out, it may not return in exactly the amount of time specified in the timeout parameter.

–Mark

11

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

12

“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

13

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 :slightly_smiling_face: .

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.

14

“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 :slightly_smiling_face: .
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.

15

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.