Understanding Draw Calls.

Discussion and feedback on Construct 2

Post » Thu May 18, 2017 8:02 pm

HI, i played around with your example i could not get draw call to skyrocket when changing frames. But then i tested it out in different browsers. Nw.js had 1-2% draw calls, chrome like ~4%, edge 7-8% and some real old version of Mozilla ~12%. You seem to be running Edge? maybe try other browsers and see if stuff changes. Update browser etc.
B
30
S
20
G
14
Posts: 17
Reputation: 9,874

Post » Thu May 18, 2017 8:37 pm

@SnipG Hmmmmm... I'm getting skyrocketing draw calls on edge when I change sprites, both on windows phone and my surface. but not in chrome. That's odd..... And that's my main developing devices... Is there something in the way the rendering works that is not supported in edge probably? Because it's only this case.....

I think I need to buy myself a few more testing devices.

I think I'm going bonkers soon... Been struggling like a madman for months to optimize the game on my windows phone to get the draw calls down and it's an edge/windows phone issue?? :evil: God dammit....

EDIT: Is it possible to have some mobile specific optimizations, because I still think that the texture swapping and too many draws still could be a bit of an issue on mobile, maybe not very noticeable on desktop devices, but as I said before, Those doing large projects, and mobile projects seem to notice "something".
Follow my progress on Twitter
or in this thread Archer Devlog
B
35
S
15
G
17
Posts: 944
Reputation: 12,210

Post » Fri May 19, 2017 11:03 am

I've already explained this, and you're just going over the same thing again. This is unique to C2 preview mode only. There's also still no evidence this actually impacts performance in a meaningful way.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Fri May 19, 2017 11:25 am

Ashley wrote:This is unique to C2 preview mode only.


No, that's from an exported html5 project on my host. I'm gonna run this gif by some other dev friends of mine for a second opinion, if this looks normal. :)

Image
Follow my progress on Twitter
or in this thread Archer Devlog
B
35
S
15
G
17
Posts: 944
Reputation: 12,210

Post » Fri May 19, 2017 11:36 am

Did you try with C3? It has a better spritesheeting engine. Again though, there's still no evidence this is actively causing any performance issues. Each individual draw call as a tiny overhead.

Avoiding texture swaps is really hard and makes potentially worse tradeoffs. For example the ultimate way to avoid texture changes is to place absolutely everything on to one single giant spritesheet, so there is only one texture which never needs to be changed. However that reverses the benefits of layout-by-layout loading and guarantees that your game will use the maximum amount of memory at all times, which is wasteful and can cause many games to crash on some devices. Then there's the maximum texture size, so sometimes you have to spill over to another texture.

So there is no evidence this is actually too slow, and "fixing" it could easily make things a lot worse.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Fri May 19, 2017 11:49 am

Ashley wrote:Did you try with C3? It has a better spritesheeting engine. Again though, there's still no evidence this is actively causing any performance issues. Each individual draw call as a tiny overhead.

Avoiding texture swaps is really hard and makes potentially worse tradeoffs. For example the ultimate way to avoid texture changes is to place absolutely everything on to one single giant spritesheet, so there is only one texture which never needs to be changed. However that reverses the benefits of layout-by-layout loading and guarantees that your game will use the maximum amount of memory at all times, which is wasteful and can cause many games to crash on some devices. Then there's the maximum texture size, so sometimes you have to spill over to another texture.

So there is no evidence this is actually too slow, and "fixing" it could easily make things a lot worse.


I'd be happy to try in C3, as I did notice that it bundle even art from other sprites in the same sprite maps. But my project is currently stuck in C2 because of plugin dependencies (photon cloud, and raytracer). Would It be possible to have an option in export for C2/C3 to manually set a target sprite map size? That way we could have a little bit more control and reducing number of sprite maps, and swapping/draws?

What's the current maximum?

So would you recommend me trying to bundle most/all of my artwork into the same sprite in C2 for now, or sprite maps as that seems to be the only thing I could do so far to control it somewhat? fewer sprites/swaps/draws seems to equal a better performance especially on mobile.
Follow my progress on Twitter
or in this thread Archer Devlog
B
35
S
15
G
17
Posts: 944
Reputation: 12,210

Post » Fri May 19, 2017 5:06 pm

tunepunk wrote:Would It be possible to have an option in export for C2/C3 to manually set a target sprite map size? That way we could have a little bit more control and reducing number of sprite maps, and swapping/draws?

It already uses the biggest widely supported maximum texture size at 2048x2048 (therefore minimising draw calls), with the exception to use smaller sheets where it would save memory (also a big concern). Any option to change this would only be able to set a smaller limit, increasing the draw calls as it has to swap textures more frequently.

So would you recommend me trying to bundle most/all of my artwork into the same sprite in C2 for now, or sprite maps as that seems to be the only thing I could do so far to control it somewhat?

I would recommend you ignore the problem because most of the time it doesn't matter.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Mon May 22, 2017 6:48 pm

Interesting.
B
33
S
18
G
12
Posts: 230
Reputation: 9,519

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: Darth Crusher, Litoghvgvgv and 12 guests