Ashely Sent you a project file on mail.

Draw calls is another matter really, and happens on the CPU side. It's probably best to split that topic off to a new thread. We have OpenGL ES 3 equivalent capabilities with WebGL 2 though, so if at any point draw calls prove to be a bottleneck, it's something we can potentially optimise in exactly the same way a native app would adjust their draw calls to be more efficient. Most 3D APIs, WebGL included, are specifically designed to allow as much drawing as possible with the fewest draw calls, to as far as possible eliminate the CPU overhead.

I'm not a programmer, but I just feel that drawing, and draw calls is not very optimized currently. Like it's drawing every single sprite, multiple times per frame, instead of drawing from a buffer, lot of things at once.

And it feels like there's a lot of overhead currently. And that there's a lot of room for improvement. Especially when it comes to draw calls and rendering.

[quote:2pwvp7hf] - next I tested drawing with ANGLE_instanced_arrays, object positions are computed on CPU, written to a (double-buffered) dynamic vertex buffer, and then rendered with a single draw call, in Chrome on Windows with NVIDIA I can get 450k instances before the performance drops below 60fps (so 450k particle position updates per frame in JS, and no sweat!), performance in a native app isn't better here, my suspicion is that the vertex buffer update is the limiter here (500k instances means 8MByte of dynamic vertex data shuffled to the GPU each frame), on my OSX MBP I can go up to about 180k instances (again very likely vertex throughput limited). However in this case, the way the dynamic vertex buffer works is also important, it looks like vertex buffer orphaning is useless in WebGL (see discussion here: https://groups.google.com/forum/#!topic ... MNXSNRAg8M), so I switched to double-buffering

Reading that quite it seems some people seem to be getting way more performance out of WebGL that we currently can in C2/C3, which I believe is due to overhead. Maybe both from draw calls and the way it is rendered? Any possibility there's something to this?

I'm not a engine programmer, I'm a designer, but it just seems C2/C3 could perform a lot better, than it currently is, by minimizing overhead.

Ashley No problem, i can send over the actual project. Where do I send it as I don't want to share it publicly?

In my own project, checking the debugger I always notice draw calls using most CPU, more than all my game logic combined. Even if I'm not using any Blend modes, WebGL effects, particles, etc. I want to understand why it is so high and what I can do to reduce it.

The only way I found to reduce it is to reduce the number of sprites on screen. Sometimes even merging graphics to one big sprite to reduce draw calls (but uses more memory). And as Draw calls goes up, I can notice frame rate dropping.

My question goes out to the Ashley and the devs, if there's anything more they can do on their end to optimize this further on their and, and enlighten us a bit more of how it works and why it's using that much CPU. This seems to be a huge CPU hog even for simple games. Especially for me as I'm designing for mobile.

https://docs.google.com/presentation/d/12AGAUmElB0oOBgbEEBfhABkIMCL3CUX7kdAPLuwZ964/edit#slide=id.i0

Found this presentation document for a good read on WebGL, I'm just trying to understand a little bit more on how it works. I have no doubt in my mind that it can match performance of native if optimized the right way. The only thing I'm not sure of is if C2/C3 is getting the most out of it. Since a lot of people still seem to be complaining about it.

Maybe both are right? Ashley claiming close to native level performance (which probably is true in an optimal case), but users are experiencing something else with their projects because it's not optimized?

What do I know? Just speculating...

Ashley

I don't know if any of this makes any sense to you (I'm not a coder), but i just tried the WebGl inspector in Firefox. This looks like a lot of draw calls for 1 frame, where good practice (from what I've read) is to bundle them and draw all sprites at once. Is there any way to optimize this further?

And Gecko seems to be using most CPU time.

As I've said I'm not doubting webGL performance. I'm just suspecting we could get more bang for the buck if C2/C3 was optimized in such a way to reduce draw calls to a minimum. Since overhead is the major issue with webGL. Known fact. That's why people it's good practice to draw many things at once. Otimal is to draw 1 time per frame.

Any thoughts on that? Is there anything that can be done to reduce # of draw calls you think?

I think it's always been like that.

X - is usually left to right. (horizontal)

Y - vertical.

Z - depth.

I know sometimes if just feels wrong i don't know why. :p

I think all modern OSs double buffer everything on-screen. Certainly all modern graphics applications do.

I was under the impression that was something you have to setup manually?

http://stackoverflow.com/questions/29565026/how-to-implement-vbo-double-buffering-in-webgl

Anyway, from what I've read, the main issue with webGL is draw call overhead, so reducing that should improve the performance a lot.

[quote:1n0y2rq9]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.

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

I'm not doubting the power of WebGL, vs Native, I just feel it's not really optimized when using C2/C3.

Ashley

Is C2/C3 taking advantage of double buffering to reduce draw calls? Check my previous post, my only issue for my own game on mobile is draw calls, so maybe there's something to it?

The only reason WebGL might perform slower than native is due to overhead, which should be reduced to a minimum for WebGL.

I've been following this topic a while, and from what I understand and read is that a WebGL application on Windows can beat a native desktop OSX application, because the OSX OpenGL driver sucks.

On windows a native desktop application can easily have 10x more draw call throughput then a WebGL app running on the same machine, BUT not because of slow JS performance, but because of WebGL overhead.

So what people do to combat this is to reduce the amount of draw calls to WebGl.

[quote:1b3hksbp] - next I tested drawing with ANGLE_instanced_arrays, object positions are computed on CPU, written to a (double-buffered) dynamic vertex buffer, and then rendered with a single draw call, in Chrome on Windows with NVIDIA I can get 450k instances before the performance drops below 60fps (so 450k particle position updates per frame in JS, and no sweat!), performance in a native app isn't better here, my suspicion is that the vertex buffer update is the limiter here (500k instances means 8MByte of dynamic vertex data shuffled to the GPU each frame), on my OSX MBP I can go up to about 180k instances (again very likely vertex throughput limited). However in this case, the way the dynamic vertex buffer works is also important, it looks like vertex buffer orphaning is useless in WebGL (see discussion here: https://groups.google.com/forum/#!topic ... MNXSNRAg8M), so I switched to double-buffering

I don't know how well C2/C3 handles this, but it might just be the case it's the draw call overhead, and why many people experience it as slow?

Edit: I'm pretty certain the only performance issues with C2/C3 is overhead, nothing else...

The C3 example, "Quad issue performance test" should probably be able to do double ammount of sprites without breaking a sweat if draw calls were reduced.

Ahhh nice trick, everyone should know about it. It's really annoying that you're always taken to the dropbox page when clicking a dropbox link nowadays.

with dl=0 you can't even right click the link for direct download.

dl=1 should be standard.

Hopefully they wont break download links again.

That one seems a bit too tiny to get any actual work done.

I'm using a Surface pro 4. Big screen, and working with Touch/Stylus only works well. There are similar cheaper devices if it's too pricey. But having touch directly on the development device is awesome especially if you're doing mobile games, to try the games directly.

C2/C3 is surprisingly usable even without keyboard/mouse. Just using on screen keyboard for expressions etc.

Big plus, is also ability to draw your art on the device, with the stylus.

Ashley

Game engines are a bit of a special case. People work on long term projects and absolutely do not want automatic updates to the editor or runtime. There's a reason Unity has every old release available for download, and even releases patches for old versions of the engine. Once you're on a release it can be a big headache to upgrade even one version ahead. You have to study patch notes like crazy and see if they apply to you. You have to re-test the entire game and hope nothing broke. Every little fix or change in a new version can heavily affect a big project. Will users be able to launch the release version of their choice when launching construct 3? If that's not an option on all platforms, that's a pretty big problem. You don't want someone on Chrome OS to always be running the latest version automatically. Users MUST be able to freeze their release version for stability reasons, including if there's no standalone versions. And users should be warned when saving an older version project to a new version.

Makes sense, I wouldn't want my game to break due to an auto-update. But that would be an easy fix in settings I guess. Turn off auto updates.

Otherwise.

https://www.construct.net/mt/make-games/releases

They seem have all previous releases here though, not sure if cashed version reverts back to old version though, but it seems you can have multiple cashed versions. Just pick your desired release.