Hey there, so I’ve been working on a game which all of a sudden started running at 40 fps rather than a consistent 60 fps for no apparent reason. It took me a while to realize that it was because my Roku updated. I realized this because I tried another Roku which hadn’t recieved the update and it worked fine, until I updated that Roku as well and I was back to 40 fps.
I originally thought maybe this had something to do with the new profiler running in the background so I created a temporary private channel so the game wouldn’t be side loaded, but it ran the same. I tried to narrow it down to which parts of my code were the most time consuming and couldn’t find anything specific until I tried putting a timer on this one method…
It’s almost perfectly alternating between being ~7ms one frame and 20+ms the next. Well 16.666ms between each frame would be 60fps so just this one call alone is taking longer than that.
Anyone have any thoughts on this? I also put a timer on my entire game loop, where all of the logic and drawing to the screen occurs, and the total for all of it is never greater than 10ms which is easily a consistent 60fps. It’s the SwapBuffers() call that is killing me.
Something changed. All my stuff is 2D API and the only way i can describe it is that it’s as if roScreen is being given less CPU time. I’ve had to “optimize” things that worked just fine before to keep the screen from flashing. I’ve noticed flashing on the Home screen too.
Hey there, I tried this on two Roku 3’s with the same results. One is Model #4230X1 and the other is Model #4200X. I could try it on my older stick and Roku 1 lol, but those are very outdated and underpowered in the first place. I still need to buy a Roku from the newer line, I don’t have any of those to test on unfortunately.
Maybe squirreltown can confirm the issue on other models beyond what I own?
“Romans_I_XVI” wrote:
Maybe squirreltown can confirm the issue on other models beyond what I own?
Would love to but mine are 4200X’s too. That said, the behavior was exactly the same on all 3 that I have.
I’m very interested in this issue and it’s resolution.
Romans_I_XVI, I’m curious about your test results - why would it have that alternating pattern usually but not always? Some of them were two short ones in a row or two long ones in a row, very odd.
Also, I just went out and bought a new Roku Stick and although I can’t compare pre 7.6 performance I can say it’s not doing the weird alternating timing on the swapbuffers(). The game actually runs better on the stick, with a constant 55 FPS and the SwapBuffers() takes a consistent 15ms during gameplay. Again, I’m not sure if it would have run better pre update or not, but again I do get better performance on the stick than on the Roku 3.
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.
“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.)
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.
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
“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
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.
“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.
Ah nice, I’m glad to hear it’s fixed on 7.7. I’ll probably just move forward with publishing and hope that the firmware update goes out sooner than later.
