3 ms·
I've done a bit of game development for the Web. Unless things have changed very recently, a major performance bottleneck is draw calls. It feels a lot more l
by rdw 10y ago
I've done a bit of game development for the Web. Unless things have changed very recently, a major performance bottleneck is draw calls. It feels a lot more like a mobile platform (< 100 draw calls) than a desktop platform (1000 draw calls). Unfortunately, it's quite an effort to reduce draw calls without making graphics compromises, curious how well Construct 2 does there.
If you have the data, I'm curious to know what proportion of games are fillrate bound vs draw call bound vs cpu bound.
- AshleysBrain 10y agoIn most cases, draw calls aren't a problem for us - the OpenGL API (and WebGL inherits this) is designed to be able to batch a lot of work with few draw calls, and the Construct 2 WebGL renderer uses a batching system accordingly. (Note we have a 2D game engine so it's a bit less demanding.) Of course you can make worst-case scenarios which issue lots of separate draw calls, but most cases work nicely. For example if you create 1000 of the same sprite in Construct 2, it can issue a single drawElements call to render them all in one go.
- sharpneli 10y agoFor 2D games where you can batch heavily (Textures in atlas, single material) WebGL is fine. And for games like that it indeed does not make sense to go native if it works fine on all target platforms. Except if you care about power consumption. For modern 3D game, even in mobile, you do need way more than that and 100 draw calls is very limiting.