Roku Developer Program

[Romans_I_XVI]

To reproduce the numbers I mentioned you could do something like this.

scr = createObject("roScreen", true, 1280, 720)
tm = createObject("roTimeSpan")
delays = []
for i = 1 to 100
    tm.mark()
    scr.clear(rnd(2^31))
    for k = 0 to 100
           scr.DrawRect(rnd(1000), rnd(1000), rnd(1000), rnd(1000), rnd(2^31))
    end for
    scr.swapBuffers()
    delays.push(tm.totalMilliSeconds())
next
? delays

I added in 100 rectangle draw calls. I know 100 draw calls per loop is a bit much for the Roku regardless, but how does this effect how much time it takes to call swapbuffers()? The output of this will be alternating between ~16ms and ~33ms but the inconsistency is not the fault of the draw calls, if you move the timer to just check how much time it takes to process the 100 draw calls you will get a consistent 7ms (aside from a few hiccups).

I feel like something might be going wonky with swapbuffers() and it's relation to vsync? But that of course is just a wild guess, I only say that because it jumps from 16ms to 33ms which would be the next frame of a TV running at 60Hz, it's like it's skipping frames.

[squirreltown]

"RokuNB" wrote:
Can you guys please try the following on different players and let me know the results?

 i ran this on my 4200x and got [ 30, 10, then 16's to the end.]

Romans_I_XVI, my experience has been that it's the amount of pixels being drawn that is significant. I'm sure the number of calls matter at some point but I have a screensaver with a full-screen background region, and 300+ "dots" that fly around in a flock. The dots scale up and down from 5 to 20 pixels. I have it set at 360 dots now, but it doesn't start stuttering until I get over 400. Now, that said, the limit of full screen images that can be run at the same time seems to be 5.

when i ran your version I got [ 74,33,56,27,16,39,27,39,27,16,33,39,16, like that to the end. ( looks kind of cool too.)

[RokuMarkn]

There was a performance problem identified in 7.6 related to frame swapping that affects only 42xx models.  Has anyone seen this issue in any non-42xx models?  If it's only appearing on 42xx models, it sounds like the same problem.  The fix has been implemented but has not yet been released.

--Mark

[Romans_I_XVI]

Ah that sounds like exactly the same issue RokuMarkn. I don't have a ton of models to test but so far it appears to just be 42xx models. I know the Roku Stick I just bought seems to work as expected. I'm glad to hear the problem has been identified and fixed! I'll probably just continue development as planned and wait for that fix 😉

[NB_]

Running Romans' code on #4640 i get the 16 (+/-1)ms and on #2500 i get
40 27 32 30 41 35 31 35 39 33 34 32 32 29 32 33 31 27 33 34 29 32 34 32 32 33 31 29 30 33 32 34 32 34 32 34 35 33 30 32 29 36 32 32 30 30 32 33 31 32 31 30 30 33 32 32 27 46 27 34 36 35 29 34 31 32 32 31 34 44 31 31 32 33 35 31 33 30 31 33 30 32 32 31 35 30 30 29 29 30 32 34 37 33 34 30 32 30 30 35
which seems... okay for a slow player.

On a 4230 w/7.6.4120 though i get the "ringing":
90 33 55 27 23 49 27 16 16 33 55 27 16 16 33 16 33 16 39 28 32 39 27 16 33 33 39 27 16 33 16 33 16 16 33 16 33 16 33 16 49 39 27 16 33 16 33 16 33 16 33 16 16 33 16 33 16 39 27 16 33 16 33 16 33 16 33 32 33 16 33 16 33 16 33 16 33 16 33 16 50 50 33 16 33 16 33 16 33 16 16 33 16 33 16 33 16 33 16 33

Same 4230 w/7.5.4099 seems "more stable":
70 26 39 15 25 53 24 32 20 30 41 23 20 31 31 22 27 34 31 26 50 18 21 30 19 31 22 30 32 33 30 22 30 28 24 30 30 21 28 19 73 18 25 31 31 21 29 18 33 28 19 20 28 21 30 22 26 22 29 21 33 27 22 27 23 26 22 26 21 28 21 30 19 33 32 30 21 28 19 29 34 56 21 20 18 23 27 20 27 23 28 22 27 33 22 25 20 32 33 35

But if you calculate the average time per frame, it remains 27ms for both. What has changed is the delta between two frames - the avg.absolute value for 7.5 was 9ms and is 15ms for 7.6. From what i see, performance has not dropped but some frames take longer, where other take shorter by the same amount

[NB_]

"Romans_I_XVI" wrote:
I'm glad to hear the problem has been identified and fixed! I'll probably just continue development as planned and wait for that fix 😉

For all i know, you may even be pleasantly surprised with the performance in the next release 8-). But hey - enroll in the beta to see more

[marcelo_cabral]

I reported this issue early on 7.6 beta, but it was not fixed, I hope this will be addressed on 7.7

[Romans_I_XVI]

I don't suppose we have any sort of time frame on when this update will come out? I am really close to being done with this game, I optimized it so it runs smooth as butter on the Roku stick (the least powerful device I am targeting for games), but it still is choppy on the Roku 3. Since Roku 3 was such a popular Roku, and most people who have one assume the games will work on it, I would prefer to have it run well on there when I release.

Thanks

[NB_]

Isn't the next dev.beta going on right now? It is a good chance to try and see - and also raise red flags if any issues

[marcelo_cabral]

"RokuNB" wrote:
Isn't the next dev.beta going on right now? It is a good chance to try and see - and also raise red flags if any issues

I can confirm that the beta 7.7 fixed this issue, the intro animation of my Donkey Kong Roku implementation was my benchmark, it now works synchronized.