photon cloud, very easy to use and understand. you can have games running as long as there is players in the room. no host or peer.

I FOUND IT!!! AND I WAS RIGHT!!!!

I created a completely new layout with the same kind of sprites that i use in my game, only this time much tighter packed, on different layers so there should be a lot more overlap and fillrate even. Wholla, way lower CPU for draw calls.

Now for the fun part.

Then i selected some of the sprites and changed their animation frame to another one where there is other sprite artwork. WHOLLA! Draw calls shooting through the roof!!! with same ammmount of sprites. It is FOR SURE something with the draw calls, and texture swapping!!!

Ashley you need to look over it. I knew I wasn't crazy!

The more different kind of sprites I use have the slower it gets, and it's because the draw call overhead and texture swapping seen HERE! I could even recreate it. EDIT: Maybe it's specific to Edge and Windows phone, but there must be some thing to mimimize this, as it doesn't seem to like it.

Here is a link to capx, to confirm. The only thing you need to do i select some groups of random objects, and change their initial frame.

https://www.dropbox.com/s/q5fr4y6mks63q ... .capx?dl=1

Is this proof enough? My game is not badly coded, I'm not using a lot of unneccesary effects and blend modes. What is causing this?

I'm not talking desktop, I'm talking about mobile. Draw calls according to debugger, uses A LOT of CPU time, amost on par with all my game logic, collission checks and everything else combined. And I don't understand why..

No effects, No Force own texture, No blend modes, Not a lot of sprites, no webGL effects.

This test on my mobile... 7500 sprites, no problem.

https://www.scirra.com/demos/c2/quadissueperf/

Bunnymark 1500 sprites juping around, no problem.

http://www.goodboydigital.com/pixijs/bunnymark/

My game. rasing spritecount from 300 to 1000 sprites, in the entire layout.

then the fps drops to 30 on the same phone.

It can't be fill rate, the game is pretty barren so far, not even all of the sprites in yet. The only thing is a little bit of texture overlap, since it's isometric perspective.

So what is it? The only thing i see on the debugger is draw calls, draw calls, draw calls, way up there. Fill rate? Bottleneck? What is causing it, and how do I lower it? If it is something that I'm doing, there should be a comprehensive tutorial on how to lower it.

It's driving me nuts!

There is nothing to gain by improving this. It looks like it's submitting about 2500 sprites at a time, which means the draw call overhead is about 0.04% of the naive case of one call per sprite. If we increased this to say 5000, it would make such a tiny difference it is totally irrelevant (0.02%), while increasing memory usage and latency. So like most engineering tasks there's a tradeoff here, and we've aimed at a good sweet spot.

I can understand why you're doing that, with a lot of sprites. Bunnymark is doing the same thing, only their limit is a lot higher. They are doing 3 draws for 60.000 sprites.

But in my game, I don't have a lot of sprites... currently 350 in layout, only a few on screen. But the draw and texture swapping is still apparent, quite a lot of texture swapping and draws for very few sprites, so even if the drawing workload is pretty small, for a mobile phone that's pretty weak, something is causing it to slow down. Even with just a few sprites on screen.

How to get around it? Can it be the texture swapping that has overhead?, Looking at the WebGL inspector, it's drawing a few sprites, switching texture, drawing a few more sprites, switching again, drawing a few more sprites, over and over like that, each frame, in multiple layers. Not even near 2500 sprites per draw. Maybe maximum 10. So there must be something causing the slowdown.

I imagine, if I were to put all my sprites into one spritesheet this wouldn't happen. I'm curious to try it on C3, as it's much smarter when generating the spritesheets, but I can't test this project there yet, as there's no photon cloud plugin so far.

Exporting from C3, I can see that even separate sprite objects are on the same sprite sheet, In C2 this is not the case.

So is it possible in C2 that the overhead is caused by the texture swapping, and unnecessary many draw calls due to that.?

Ashley - if the GPU fillrate is bottle-necking literally everything, then how do we fix it?

Have all your artwork in 1 sprite object, seems to help. A pain in the ass to work with though.

But I think it's starting to lean more towards some texture switching rather than GPU bottleneck.

[quote:28hu49fx]Your screenshot shows FPS < 60 and CPU well under 100%, which is typically indicative of the GPU hardware being the bottleneck.

[quote:28hu49fx]Sorry, but I don't think you actually understand how WebGL rendering works.

You're absolutely right I don't, that's why I'm doing everything in my power to investigate why I'm getting bad performance on mobile.

I made a gif to try to show you what I mean.

This doesn't look very efficient to me. And I'm not a WebGl guru, but from what I've read, you should be minimizing draws to a minimum for webGL. This doesn't look like 1 draw per frame from one array, This ilooks like several drawElements, layer upon layer. You can see the blue dots building up to the right.

But anyway, so your example is rendering 7500 sprites but my game only a few hundred, on the Same Phone!? I doubt it's GPU bottleneck. Other webGL examples and games are not bottlenecked, why only C2 games with lots of different sprites?

I'm only guessing it has something to do with how the rendering is done.

As I said. Merging most my artwork in to the same sprite, by using Animations and frames, seems to have a positive effect. So the only way to get around the bottleneck is to merge all sprites to one huge spritesheet? I want to go to the bottom of this. I shouldn't be getting 30fps with a couple of static sprites on screen.

Anyway.... I'm going to set up a few different capx tests to further test this.

Maybe that will help in finding out why, performance is dropping significantly, when using a lot of sprites from diffrent spritesheets, but not when using 1 sprite or 1 spritesheet (texture)

https://www.scirra.com/demos/c2/quadissueperf/

I tried this test on my phone, getting 7600 sprites on screen, at 30fps.

So how do you explain then, Why I can't even have a few hundred static sprites on game screen without hitting 30fps on the same mobile?

What is causing the slowdown then?, if it's not the draw calls and not the rendering? I there must be something causing it! And I can't find anything else to improve what I'm doing at the moment. Your Stress tests 7000 sprites on screen no problem... my project, not even a few hundred.

I want to know why.... my only explanation is some kind of overhead.

Your screenshot shows FPS < 60 and CPU well under 100%, which is typically indicative of the GPU hardware being the bottleneck. So there's no evidence draw calls are the limitation there.

[quote:lmn072l8]

Fewer, larger draw operations will improve performance. If you have 1000 sprites to paint, try to do it as a single drawArrays() or drawElements() call. You can draw degenerate (flat) triangles if you need to draw discontinuous objects as a single drawArrays() call[/code:lmn072l8]. 
that's exactly what bunnymark is doing when I check the webGL inspecitor.

Using a webGL inspector i can clearly see you're not doing that! As I said you may not notice it, for small games on powerful devices, but you will notice it for LARGE games, and Mobile games.

The engine does already do that, with a sophisticated batching engine. But changing texture is one of the operations that has to split the batch. In C3, or after export, textures are merged in to spritesheets and the batching works better since there are fewer texture swaps.

So we're already doing everything you've asked for.

No it doesn't! Use a WebGl inspector and check for your self! The aim should be 1 draw per frame, that's it! Yes and splitting the batch you're creating 100's of draw, where you could be doing a single one, with all the sprites in one go!

Stepping through the C2 draws, I can see what you're explaining... some things are batched together, drawing layer upon layer 100 times per frame, where you SHOULD be drawing 1 time per frame as the bunnymark example is doing. All the sprites in one go!! The implementation is sloppy, It's doing it completely wrong with loads of unnecessary overhead.

There IS an overhead issue, and it scales directly with number of sprites(draws), as you're rending layer upon layer of "drawElements", where all of it could be drawn in one go.

I'm getting lots draws per frame, layer upon layer, upon layer, and i can step through them one by one to see how it's layered.

Bunnymark is using 1 draw per frame, as you SHOULD be aiming for, no matter how many bunnies on screen, it's always 1 draw per frame.

I don't even know why I have to point out the obvious?

Do I have your permission to modify c2runtime.js and do it the right way?

You're worrying over nothing. There is nothing here to suggest any performance problems.

Are you kidding me? Here's a new screenshot.... The only thing i did was to increase the number of sprites in layout to about 1000... Take notice... IN LAYOUT, not on screen, none of them are moving, just static sprites, and framerate dropped to 30fps.

Draw calls also increase along with the number of sprites, becuase you're not using buffers!

Of course, 100draw calls is not very much for a small game on a powerful device, but people doing large games and games for mobile ARE noticing the bad performance. Because, you're not even implementing best practices... general things you should do.

https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/WebGL_best_practices

Fewer, larger draw operations will improve performance. If you have 1000 sprites to paint, try to do it as a single drawArrays() or drawElements() call. You can draw degenerate (flat) triangles if you need to draw discontinuous objects as a single drawArrays() call[/code:38chx5cy]. 
that's exactly what bunnymark is doing when I check the webGL inspecitor.

Using a webGL inspector i can clearly see you're not doing that! As I said you may not notice it, for small games on powerful devices, but you will notice it for LARGE games, and Mobile games.

Please please please....  Just try to look in to at least using best practices, and use a drawArray. It's a known fact that WebGL overhead is an issue, and you're doing nothing to minimize it.

Or is my only option to modify c2runtime.js myself to prove you wrong?

I can easily say that just by that little tweak we would get a LOT better performance.

If I'm wrong I'd be happy to send you a fine bottle of whiskey.
If you're wrong, the only thing you have to lose is a little time, and getting more happy customers because of a small tweak to how things are drawn

This thread should have enough solid proof now that the way C2 does the rendering is not very efficient at all, considering it's WebGL, and what it should be capable of.

If you can provide a minimal .capx that shows high draw call usage, I'd be happy to investigate optimising the engine. Without that the most I can do is speculate.

So get on with it

I'd be happy to play with the new superfast C2, C3, once the optimizations are in

Testing bunnymark VS my construct project rendering There is way less calls here, and far more bang for the buck. Looking at the WebGL inspector they are rendering things differently than C2 does. Seems to be using buffers.

It seems the way C2 render stuff has a LOT more overhead...

http://www.goodboydigital.com/pixijs/bunnymark/

here's the link to bunnymark if anyone want to try it on their phone to test performance.

I can have 1500 bunnies jumping around on a midrange (Nokia Lumia 830) before framerate goes below full 60fps.

My construct project is struggling the same phone with 50 static object on screen. No animations, nothing moving.

Here's a screenshot from my game, at an area with very few objects, CPU is pretty high, mostly due to draw calls. Framrate is getting low. About 50ish, with just a few static objects on the map.

Here's a screenshot of Bunnymark with a lots of objects jumping around. at a similar framerate 60fps.

I'm pretty confident that Ashley claiming near native performance is possible with WebGL, but not with the current implementation, as it's REALLY inefficient.

Please take a look at this.... it's not only me experiencing bad performance, i think construct can do it better. It's just sloppy implementation, and bad optimization.

And I think this should be a first priority, as people are choosing other engines due to performance issues.

I also noticed that I was able to get a good amount of performance boost, by merging most of my assets to as few sprites as possible, adding all assets to different frames, and animations, as everything is rendered "per texture", so that they are in the same spritesheet. If I wasn't doing that I wouldn't be getting as good performance as I currently am.

So, my conclusion... use as few sprites as possible, but add all assets to the same sprite will increase performance, since they then will be on the same "TEXTURE" (spritesheet), will result in fewer draw calls, less overhead, and less drawing per frame.

I was checking the c2runtime.js webGL the whole GL section.

Are we allowed to modify c2runtime.js?, because i would like to make some test to see if I could make some improvements there.