Roku Developer Program

[Romans_I_XVI]

So I am using this wacky code to randomly select from 1 of 4 bitmaps and 1 of 4 rotation angles thus giving me 16 different looking images displayed randomly which creates a nice electricity effect for my shield. This works great on my Roku 3 but I was just testing on my Roku 1 today and well the performance is horrible.

                if this.shield_on
                    if this.shield_animation_timer.TotalMilliseconds() > 50
                        this.rnd_shield_old = this.rnd_shield
                        this.rnd_shield_rotation_old = this.rnd_shield_rotation
                        this.shield_animation_timer.Mark()
                        set_shield_animation:
                        this.rnd_shield = cint(rnd(4)-1)
                        this.rnd_shield_rotation = 90 * cint(rnd(4)-1)
                        this.x_offset = 0
                        this.y_offset = 0
                        if this.rnd_shield_rotation = 90
                            this.y_offset = 150
                        else if this.rnd_shield_rotation = 180
                            this.y_offset = 150
                            this.x_offset = 150
                        else if this.rnd_shield_rotation = 270
                            this.x_offset = 150
                        end if
                        if this.rnd_shield_rotation = this.rnd_shield_rotation_old and this.rnd_shield = this.rnd_shield_old
                            goto set_shield_animation
                        end if
                    end if
                    this.screen.DrawRotatedObject(this.spr_ship_x-33-10+this.x_offset, this.ship_y-21-10+this.y_offset, this.rnd_shield_rotation, this.bm_shield[this.rnd_shield], m.ship_color[m.active_ship].shield.hex)
                end if

So the question is, is there a performance difference between these various forms of drawing to the screen:

• Drawing sprites that are in the compositor using compositor.DrawAll()


• Using screen.DrawObject()


• Using screen.DrawScaledObject()


• Using screen.DrawRotatedObject()

I guess it makes sense that if the game needs to handle rotating the image first it would take time, I just didn't think it would have this much of a performance hit.

Also note that I am colorifying (IDK the term but gimp calls it this) the shield using the optional hex color argument. Not sure if that could affect it as well.

I know that I could swap out DrawScaledObject() and DrawObject() temporarily to see what it does ( and I probably will ) but I just thought I'd see if anyone else has thoughts on this topic.

Cheers

[Komag]

I have noted that drawRotatedObject() has a HUGE impact on performance compared to the same pic using just drawObject(). Haven't tried scaled. So I don't ever use it, at all, EVER. I just pre-rotate and make more sprite options. (I don't yet have a Roku 3)

The compositor seems very fast. What I don't know is if it's just the same as a bunch of drawObject()s or if it's faster.

[Romans_I_XVI]

Yeah I switched it so I'm now using 16 sprites. Completely fixes the performance problem. I've always been a person who, if I am able to acomplished a task with an automated piece of code, I would choose that over the more obvious choice of just creating a bunch of sprites. But that changes a bit on the Roku when processing power is limited.

The rotation wasn't that helpful anyway, on my Android game I'm telling it to rotate to a random angle anywhere from 0-360. The Roku can only do 90 degree changes.

Anyway, it's working good now and looks the same as it did before. Serves me right for developing on the most powerful device and then testing on others...

[TheEndless]

"Romans_I_XVI" wrote:
The Roku can only do 90 degree changes.

On the Roku 3, the new Roku 2, the streaming stick, and the old Roku 2 XD and Roku 2 XS, it can rotate the full 360 degrees. 90 degree rotation seems to be a limitation of the non-OpenGL models.

[Romans_I_XVI]

Oh, thanks for the info TheEndless. Guess I was just going off the documentation. Maybe once the less powerful models are phased out I can actually use it.

[squirreltown]

"TheEndless" wrote:
the new Roku 2,

Confirmed or still edumacadedly guessing?

[TheEndless]

"squirreltown" wrote:

"TheEndless" wrote:
the new Roku 2,

Confirmed or still edumacadedly guessing?

edumacadedly.. since it has the same internals as the old and new 3, it should behave the same.

[EnTerr]

"TheEndless" wrote:
On the Roku 3, the new Roku 2, the streaming stick, and the old Roku 2 XD and Roku 2 XS, it can rotate the full 360 degrees. 90 degree rotation seems to be a limitation of the non-OpenGL models.

Also Roku 2 HD (#3000 - why do people remember 2XD and 2XS but regularly forget 2HD?! RokuCo in particular is guilty of that in support/accessories pages), Roku LT #2400 and MHL stick (#34xx). I got chided recently for promoting checks by model#. In light of that, my guess on checking for fast (and degree-able) DrawRotatedObject() is:

if createObject("roDeviceInfo").hasFeature("gaming_hardware") then ... 

@RokuMarkn - is this the right way to check for OpenGLES? (Or is "gaming_hardware" specifically about motion remote capability - or for motion remote connectedness?! ostensibly three different things)

[RokuMarkn]

The "gaming_hardware" capability refers to the ability to connect to a motion-enabled remote. In other words, the unit supports a WiFi Direct or Bluetooth remote. It doesn't change depending on what type of remote is actually being used. As far as I know, there isn't currently any easy way to detect whether OpenGL is implemented. If you really wanted to reliably detect whether nonorthogonal rotations are supported, I suppose you could rotate a small bitmap by 45 degrees and use GetByteArray to check whether it worked, although that's pretty ugly.

--Mark

[squirreltown]

Call me crazy but perhaps someone with "Roku Engineering" after their name could give a definitive list of does dat do and does dat don't, including the most recent boxes -and while they're at it, how about available 2D graphic memory for the new boxes.