Understanding Draw Calls.

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.

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?? 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".

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.

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.

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.

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.

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.

[quote:35t4rkq0]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.

Interesting.

tunepunk and — The use of excessive cpu is not good with the use of gpu, but other factors. I can transform your file using 0 to max 2% with character stopped and moving in the maximum 5% regardless of how many behavior, object, sprites or events exist. So much so that I was even thinking of doing a course on how to optimize games and apps made in c2 ... Even if there were a million sprites on the same stage, I would be able to optimize and decrease the cpu usage to a minimum of 0 to 5%

Proof:

marceloborghi

This is quite a bold statement

A million sprites, with behaviors and events? I'd love to see some examples, and would definitely be interested to know how (if) this could be done.

tunepunk Ashley In the case of the example, collision is the problem, so the scirra has created calculations of the whole stage (even outside the camera that is calculating) with the mathematics of to make two solutions, x and y comparison or to make an intelligent collision field that connects and turns off, thus dropping the cpu.

Link to example

course of optimization of games in construct 2:

viewtopic.php?f=191&t=200735&p=1162604#p1162604

Might want to do a search on collision cells before you do your Udemy course.