Is there any impact on performance when using a scaled Image or MovieClip?
I'm using almost all of my assets in this way to make them fit inside a 2048^2 texture atlas. When i create them i set the scaleX and scaleY to 2.
My question is: the performance would be the same as if the Image or MovieClip had twice the size or are there extra calculations done on every update because of the scale?
Thanks!
There is one tiny additional operation that has to be done, but that should not be noticeable. (The transformation matrix has to be scaled.)
Don't think about it -- that's fine! =)
It would be noticeable if you set the scale each update as it would set the matrix dirty and need to invalidate if you set it once it doesn't update each time. Atleast thats how I think Starling works 
If you had 10000 sprites and invalidated their matrices each frame it sure would have an impact believe me
Hehe, yeah, with 10k sprites everything would make a difference, I guess! 
I asked because i use a scaled down atlas and when creating Images and MovieClips i scale them to 2 or 3x (only during the instantiation).
I'm almost submitting the game i'm working on to the app store, however in my iPod 4 there is still some lagging (dropping below 30fps). I think this is caused by many movieclips and images moving at the same time. I did everything i could to prevent overhead in the enterframe:
- I changed the code to never remove or addchild from/to the display list (everything is just removed from the Juggler and made invisible);
- About the juggler, i thought it would be cheaper to add everything just one time and just call stop() when the mc is not in use but the fps is higher adding and removing to it;
- Of course, i instantiate everything at the startup and use only one texture atlas (2048^2);
- Surprisingly, setting the touchable property to false increased performance (maybe it should be set to false as default, and only set to true in Buttons);
I'm using retina display, and most of the Images and MovieClips i use has alpha. Many of them are big in size (300x300, some even larger) and all of them are constantly moving.
I don't know what else to do to make the game run smoothly, do you have any extra tips?
Thanks!
Surprisingly, setting the touchable property to false increased performance (maybe it should be set to false as default, and only set to true in Buttons);
Hit tests happen whenever the mouse/touch moves, and this can use a lot of CPU in a complex display list. However, if you set touchable=false on a Sprite, all of its children become untouchable too, so you can't just turn it off everywhere. Moreover, I think you may be surprised at how much people listen for touches on things other than buttons.
Anyway, that's a bit of explanation. Ultimately, yes, you should turn touches off in places where they aren't needed. It *will* improve performance, especially on mobile.
It significantly improved performance for me. But, as i said above, still not enough.
About TextureSmoothing, does setting it to none make a difference?
And what about using BlendMode.NONE just for my static background (exactly one image)? Would this help?
Sorry for so many questions, but i don't know what else to try.
- texture smoothing has very little impact on performance I was able to measure difference only when rendering thousands of sprites on low end mobile devices and the difference between NEAREST(NONE in starling) and LINEAR was around 1-3% which is not worth it.
- BlendMode.NONE has huge impact on performance on low end devices and ALWAYS use it for textures without any alpha. I mean HUGE with large sprites we are talking about up to 10 times the rendering speed. On new devices like IPad2 or Samsung Galaxy S2 there is no difference whatsoever even with thousands of sprites, I guess the GPU handles it differently.
I think I read that using TextureSmoothing.NONE has little or no impact.
BlendMode.NONE on anything that doesn't need transparency, including backgrounds, will improve performance, yes.
I see. Image quality (like using RGBA4444 instead of RGBA8888) doesn't influence anything as far as i know.
I don't know what else i could do, i think the only possible thing to do would be to use smaller assets with less alpha...
Amount of alpha if there is some doesn't matter, if there is some and you need to use a blend mode or there isn't and you can disable it.
Performance optimizations depend on a specific usecase what you are trying to do, not everything is possible to work out on devices like IPad1 obviously.
I'm moving two sprites down along the y axis, each one the size of the screen, having some children images inside. Both sprites are flattened, and i perform per-pixel collision on each of its children (i don't do this every frame, but once every 100 milliseconds).
When one of the sprites reaches the end of the screen, i remove it from the display list and change its reference to another sprite of the same kind, but with different contents (these sprites are all pre-created and stored inside a vector). Then i position it at the top of the screen, to create a moving background effect.
I also have about 10-20 movieclips crossing the screen in the x axis, using the same logic of the sprites described above. I perform rectangle intersection collision detection with these mcs.
The collisions are always tested against the player, which has its position set every frame with a touch event (the image center is always at the mouse position).
Other than that i play sounds when the player collides with something and a background music is always being played.
This is basically what i'm doing.
Ultimately, yes, you should turn touches off in places where they aren't needed.
And where they are needed (for example on deeper nested sprites) where you really just won't to get the sprite itself, it has turned out to be a good idea to override the hitTest method at some points. At least this has been the case in one of the 0.9.x versions of Starling. Not sure if there have been improvements so far.
I have a game board with approximately 60 "coins" on them. Each one again being composed out of several images. The original hit test of the board added up to a time of ~20ms per frame. Which is a lot compared to other tasks and it had a huge impact on the games FPS!!!
After rewriting the hitTest code of these coins to use a minimum of calculations (no width or height getters being used), the hitTest of the board had been reduced to less than 1ms.
It always depends on the use case, I would say. But I also still need to disable some touchable elements and use the BlendMode.NONE on more elements than just backgrounds to really get a good performance.
Kind regards,
Daniel
Yes, good point, frisk. I use a simple hitTest() override like the one below in a few places where I subclass Sprite and the children aren't touchable. _hitArea is a Rectangle.
override public function hitTest(localPoint:Point, forTouch:Boolean=false):DisplayObject { if(forTouch && (!this.visible || !this.touchable)) { return null; } return this._hitArea.containsPoint(localPoint) ? this : null; }
Hi,
I had some performance issues with too many movieclips as well. They were fruits with eyes, that open slightly time shifted. Whech means per fruit I needed two eyes. Seven fruits* 2 eyes = 14 MovieClips. This killed 5 frames even if they weren't playing in the juggler. So for any state where they were standing still I just removed the MovieClip from the EyePair-Sprite and put an Image instead. This gave back the missing 5 Frames.
I'm on iPad2 which seems to really f*** up if you put too many "moving" DisplayObjects on the scene. Android has much better handling for that.
One construction site of mine which seems to cannot be solved on iPad is here:
http://forum.starling-framework.org/topic/nape-and-starling-particle-system
You must log in to post.
