I’m creating a very simple game which uses SWF assets for graphics.
The screen is controlled with a camera which is moves every frame (mostly translates but sometimes scales and rotates). On the screen at any one time, there is 1 character consisting of a body head and limbs (all constantly moving), 8-12 clouds (again, constantly changing TRS), and around 20 floating animated sprite coins (using Joshua’s spritesheet lib).
Except for the coins, everything every visual comes from calling Asset.getMovieClip referencing an SWF full of assets.
When I target Flash at 60fps it runs pretty smoothly, but HTML5 occasionally stutters really badly, and Windows runs dog slow. Neither feel fluid and this quality is very noticable.
I’ve also noticed (possibly due to the constantly moving objects) that targeting Flash on debug mode is terribly slow due to unnecessary mouse detection. But anyway…
Assuming my code is ok, is this likely to be emerge from the use of SWF movieclip objects and their constant moving?
It appears I just can’t rely on the SWF library for much besides buttons and interface if I want to keep the performance relatively decent for non-Flash targets.
If I used nothing but bitmaps, would this generally improve matters?
I’ve seen some very impressive HTML5 run stress tests using OpenFl that boast rendering hundreds of thousands of moving objects without any lag using Tilemaps I believe.
Would it be possible to use Tilemaps if I converted my assets into a spritesheet?
What about nested MovieClips and tweening animations?
Maybe DragonBones?
Hm?
Thoughts?
There are a few layers at work here:
1.) Creation/updating of bitmap content
2.) The number of bitmaps
3.) The number of GL draw calls
Anything shape related (such as sprite.graphics and other vector-based content from a SWF) runs a risk of having to be re-rendered. In essence, vector graphics need to be converted (in software) to a bitmap. A bitmap-based rendering system (either bitmaps at compile-time, or bitmapData.draw to convert at runtime) skips this first step. The cost of the first step varies on the number of objects, and how often they are changed. This can become very expensive – though Flash has uniquely been optimized for doing this quickly – something we cannot fully reproduce using canvas on HTML5 or cairo on native platforms.
Secondly, the number of bitmaps you are rendering can make a difference. Drawing 100 objects might be slower than 1, but generally the cost is either in generating more images (as explained above) or if you are using OpenGL, the number of GL draw calls.
A Bitmap in OpenFL will be one OpenGL draw call. a Tilemap in OpenFL will be one draw call per tileset used. This means a Tilemap of 200 objects from the same tileset may not be too much more expensive than one Bitmap. However, if it must use a different Tileset per tile, then the performance will be about the same as 200 Bitmap instances.
Redrawing less often (which runs in software, and not on the GPU) is likely the most expensive of the above steps. Reducing the number of times that occurs is ideal. If you are using Adobe Animate, check the Export as Bitmap option on some objects to test the impact on performance, even if it prevents some animation from occurring for now. That’s a very fast method of testing pre-baked bitmaps without revising your code, to test the impact of software rendering
