Mobile Game Performance

Discussion and feedback on Construct 2

Post » Mon Aug 24, 2015 1:42 pm

jayderyu wrote:5. Use Plugins more than Event Sheet. Try to keep ES code to just plugin interaction. If you need a feature, find a plugin or write one in the SDK as a plugin.


Interesting. I might look in to that to see if i can get any further performance improvements.

Is there any particular events/conditions that can benefit more than others from this? If so, any recommendations?
Follow my progress on Twitter
or in this thread Archer Devlog
B
40
S
17
G
17
Posts: 992
Reputation: 12,656

Post » Mon Aug 24, 2015 2:13 pm

@Kali
This is more applicable to the GPU rendering pipeline rather than canvas. A GPU can render images extremely quickly if the GPU does not need to change the texture in the GPU memory. We are talking about 10,000's of sprites being drawn in a insignificant amount of time. A GPU stores 1 texture in the render pipeline. That texture max size is always a power of 2 square. New GPU's store 4096x 4096, however the current target standard 2048x2048. so let's pretend 2048 is your GPU's limit for this discussion.

(numbers are sample figures at this point because actual figures go into higher decimal points)
If you can store 10 "sprite" images onto 1 texture. And the gpu can draw 10k pixel fill per drawcall. Let us also set it up that there are 10 types of bullet graphics that we cycle the colour through. All of them stores in one texture. When we shoot 10k bullets, and cycle through the colours that's 1k of each bullet graphic. And let's say it takes 0.0016 of a second to make one drawcall. That will allow you to have 10k bullets drawn at 60fps. As it's only doing 1 draw call and are figure ways it's ok to draw 10pixel draws per call

ok. now let's say you make 10 sprite objects(I am talking about individual Sprite Objects, not Copy/Paste of of a single sprite object) 1 object per bullet type. The situation is the same. We are going shoot 10k bullets, cycle through creating a bullet so we will use each SpriteObject bullet 1k. Since each bullet graphic is on a different texture(details in a sec). This will force the GPU to have to swap the texture in ram for each bullet type and do another drawcall for that bullet type. So if it takes 0.0016 seconds for 1 draw call. that now takes 0.016. Which isn't 60fps anymore. it's 10 times longer. it's 10fps not 60fps.

And what's worse is what if those bullets overlap each other. Then the GPU needs to swap again back to a re-used texture because it needs to draw over an image of another texture. This could lead to even far less fps. However if you pack all 10 bullets onto 1 texture, then the gpu can write over itself a ton of times without ever needing a new draw call.

And to take advantage of drawcalls in c2. C2 packs images into textures based on Sprite Objects. So 2 different sprite Objects will be 2+ different textures. C2 will pack as many images in the frames and animations into a single texture of that Sprite as possible. However any images in a different SpriteObject will always garunteed be a different texture.

So developers who use 1 SpriteObject per graphical UI element, enemy, environmental objects are killing their performance.

@tunepunk
I doubt it would be a massive performance. In this suggestion it's more about development performance and organization. Write new features for large projects using ES is not optimal.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,028

Post » Mon Aug 24, 2015 2:32 pm

thanks @jayderyu thats a really good explanation of how it works..
Image
Get it on Google play or play on papio.nu
B
11
S
2
Posts: 79
Reputation: 786

Post » Mon Aug 24, 2015 9:02 pm

Interesting topic, many thanks ; )
B
15
S
5
Posts: 40
Reputation: 1,221

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: dand, db3344, Tombas and 9 guests