Developers

[Romans_I_XVI]

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.

[TheEndless]

"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.

[Romans_I_XVI]

"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.

[TheEndless]

"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

[Romans_I_XVI]

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?

[TheEndless]

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

[Romans_I_XVI]

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!

[Komag]

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. 🙂

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?

[Romans_I_XVI]

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.

[RokuMarkn]

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