Roku Developer Program

[Komag]

Hey, did this ever get reported or fixed? Which Rokus did it affect?

I'm trying to narrow down a flickering bug I've run into in certain situations depending on the busyness of the room I'm in with my game, and if its this bug or related to it, I'm wondering the status. I see my flickering bug on my Roku 2 XS, but being a performance-related bug, I can't rule out that it exists on my other Rokus but just not showing up do to it depending on certain framerate or vsync situations, maybe.

Is this related to this bug demo'd by oomzay?
viewtopic.php?f=34&t=83900

[NewManLiving]

What solved flickering for me was making sure I called finish on all bitmaps and regions where any type of drawing or drawing function, clearing or region offsetting was done. Anything that changes the state of a bitmap or region needs to be commited to the screen buffer before calling swapbuffers. So roBitmap.finish and roRegion.finish are synchronous and insures everything is where it should be. Now I use compositor and cannot say if the problem exists outside of it or if your problem is related. But I no longer have flickering problems on the 2xd or low end boxes

[squirreltown]

"NewManLiving" wrote:
What solved flickering for me was making sure I called finish on all bitmaps and regions where any type of drawing or drawing function, clearing or region offsetting was done. Anything that changes the state of a bitmap or region needs to be commited to the screen buffer before calling swapbuffers. So roBitmap.finish and roRegion.finish are synchronous and insures everything is where it should be. Now I use compositor and cannot say if the problem exists outside of it or if your problem is related. But I no longer have flickering problems on the 2xd or low end boxes

It's not just the compositor. I recently had a function which was tearing and flickering like nuts ( you saw it Komag) on 2XS's.
i fixed it by changing

screen.clear()
write something to bitmap in question
screen.drawobject(0,0, bitmap)
screen.swapbuffers()

to

write something to bitmap in question
screen.clear()
screen.drawobject(0,0, bitmap)
screen.swapbuffers()

[TheEndless]

"squirreltown" wrote:

"NewManLiving" wrote:
What solved flickering for me was making sure I called finish on all bitmaps and regions where any type of drawing or drawing function, clearing or region offsetting was done. Anything that changes the state of a bitmap or region needs to be commited to the screen buffer before calling swapbuffers. So roBitmap.finish and roRegion.finish are synchronous and insures everything is where it should be. Now I use compositor and cannot say if the problem exists outside of it or if your problem is related. But I no longer have flickering problems on the 2xd or low end boxes

It's not just the compositor. I recently had a function which was tearing and flickering like nuts ( you saw it Komag) on 2XS's.
i fixed it by changing

screen.clear()
write something to bitmap in question
screen.drawobject(0,0, bitmap)
screen.swapbuffers()

to

write something to bitmap in question
screen.clear()
screen.drawobject(0,0, bitmap)
screen.swapbuffers()

Yes, the key is to not dispose (or modify?) any 2D objects after you've initiated drawing to the screen. This flicker/tearing issue is restricted to the original Roku LT (2400), Roku 2 HD, Roku 2 XD, Roku 2 XS, and Roku Streaming Sticks (i.e., 2400 and all 3XXX models).

[Komag]

Thanks for the helpful replies 🙂

I tried adding an extra mainR.Finish() (most of my stuff goes to a region called mainR), and I saw no more flickering (yay!) but performance lowered about 15-20% (that alone may have slopped the flickering since the timing was now different, so it may not have actually solved anything in this case).

Instead, I tried adding screen.Clear(&h000000FF) just in front of where my compositors all DrawAll(), and that didn't affect performance in any way, and seems to have solved it! I've been running around for a while now with no flickers at all! 😄 Woohoo!

I'll keep an eye on this and test with this Roku more often

[NewManLiving]

Yes there is a slight performance hit with the finish calls. Just curious how many roscreens and how many compositors you use. (You said compositor(s)) I'm not developing a game but the app I'm developing has sometimes up to 7 z orders/layers of animated interface objects going at the same time. The main menu carousel has seven and the grids always have three then five for the splits into the selected module. Each main menu selection fades into its own module. With all this I use only one compositor and one roscreen with no problem at all

[Komag]

I have one screen but different compositors for different timing of animations, especially when some start and stop with only one cycle through but might partially overlap (in timing) others, so I can control them exactly and independently. In some cases I could just do a series of timed drawObject()s for the different "frames", but I prefer to use a compositor instead and do an AnimationTick() at the right times.

[NewManLiving]

In that case it would make sense. I never did like compositor.animationtick, got more even results using my own animationtick, but I might have been doing something wrong

[TheEndless]

"Komag" wrote:
I prefer to use a compositor instead and do an AnimationTick() at the right times.

"NewManLiving" wrote:
In that case it would make sense. I never did like compositor.animationtick, got more even results using my own animationtick, but I might have been doing something wrong

This is another one of those poorly documented things. You should be calling AnimationTick() on every pass through your loop, and using ifRegion.SetTime() on each of your animated sprite regions to control the frame timing.

[Komag]

I'll have to dig deeper into that with regions then. I need exact frame control sometimes, such as starting a small 4-frame sequence (a hit-swipe), running for only 4 frames, then removing the sprite - if I make that (and a couple other situations) work with one compositor and careful use of regions, great.

But what's the reason to try to use only one compositor, performance? buggyness with multiple? memory use?

EDIT - So it's possible to have a single compositor make sprites that go to different regions? But I thought you must select the one bitmap the compositor will draw to with SetDrawTo(destBitmap as Object, rgbaBackground as Integer), for me one compositor example is anmC.SetDrawTo(mainR, &h00000000). Is that something you change often, or is it some other way you send a sprite to a different bitmap?