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.
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.
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…
“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.
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.
“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.
“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)
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.
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.
“EnTerr” wrote:
why do people remember 2XD and 2XS but regularly forget 2HD?!
I don’t think we forget about the Roku 2 HD and the Roku LT 2400, we just overlook them. They had the shortest lifespans of any other Roku players, so the likelihood of there being a ton of them out there is low enough that it’s probably safe to overlook them.
With that said.. looks like there’s the potential I was wrong about the new Roku 2 and Roku 3. According to this chart, they don’t have OpenGL, so maybe someone does need to test that out… (assuming OpenGL support is the requirement for arbitrary rotation).
“NewManLiving” wrote:
What about the TV that is not listed as having open gl
You’ve got a TV right? Does it rotate arbitrary? without openGL? or are you saying the list is wrong?
Let me clarify that. I think TheEndless has one perhaps he can test it. I like the arbitrary rotation. Don’t like having to emulate it with region frames
“TheEndless” wrote:
With that said.. looks like there’s the potential I was wrong about the new Roku 2 and Roku 3. According to this chart, they don’t have OpenGL, so maybe someone does need to test that out… (assuming OpenGL support is the requirement for arbitrary rotation).
Eh. I wouldn’t put stock in the 4/29 update of the table. First, there are couple of mistakes in the newly added columns for 2015 Roku2 and 2015 Roku3 (wrong model model#, indicating “yes” for Voice Capable Remote for Search on 2015-Roku2). Second, the person who did that edit has history of imprecise language (i.e. omissions/incorrect) in the docs.
“squirreltown” wrote:
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.
Crickets
( I have an awesome Hollywood Edge “outdoors” SFX loop. Too bad you can’t paste sounds in here. Just imagine you’re listening to it.)
“RokuMarkn” wrote:
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.
Thank you for the clarification on “gaming_hardware”!
Separately, I thought of checking on #2400 and it indeed returns False for gaming_hardware - which makes sense, i think it doesn’t have the BT chip - but has OpenGLES.
Testing for rotation through ifDraw2D.GetByteArray() is ingenious, if somewhat evil. I suppose testing for performance can be done in analogous way, i.e. benchmark how long does it take to do a few hundred DrawRotatedObject() on the particular player and then branch out depending on result.
“NewManLiving” wrote:
Let me clarify that. I think TheEndless has one perhaps he can test it. I like the arbitrary rotation. Don’t like having to emulate it with region frames
The TV only rotates in 90 degree increments.
