Ashley's Forum Posts

  • Are you testing in C2 preview mode? That will have lots of texture swapping. It shouldn't happen so much in C3, and less after exporting in C2 (but still not as good as C3, which has a much better spritesheeting engine and combines more images on to sheets).

    GPU fillrate is usually a far bigger problem than draw calls. Spritesheeting doesn't affect it, it's to do with the number of pixels drawn to on the screen. To reduce that you have to use fewer, smaller sprites, avoid heavy overdraw (i.e. stacking lots of sprites on top of each other), and in particular avoid force-own-texture layers (which also includes layers with effects, blend modes, or opacity other than 100%)... or find a device with more fillrate

  • So that particular case touches on a pretty obscure part of the engine. Another piece of WebGL performance advice is not to submit huge buffers in one go, but to actually submit them in chunks. This also helps keep the memory usage down and reduce latency to issuing work to the GPU. So the engine issues chunks of several thousand quads at a time. In the quadissue case, it reaches extreme levels of sprite batching so you are seeing lots of chunks.

    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.

    So you are in fact looking at the batching engine working in ideal circumstances, and accusing it of bad performance. You should not jump to conclusions about parts of the engine you don't understand.

    GPU fillrate is the bottleneck that most people run in to, so that is probably the limit in your game too.

  • I already answered that:

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

  • 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!

    It already does. The entry I showed you draws all the sprites in one go. The other calls are to draw things like the text and the spinner in the corner.

    Sorry, but I don't think you actually understand how WebGL rendering works.

  • The release notes are all here: https://www.construct.net/make-games/releases

  • To prove the point, try running the WebGL inspector on https://www.scirra.com/demos/c2/quadissueperf/. It can draw over 10,000 sprites in ~50 draw calls, most of which is just overhead to render the layout and text. In fact there's just one draw call that renders most of the sprites:

    [quote:1zpii4o0]37 drawElements(TRIANGLES, 11994, UNSIGNED_SHORT, 0)

    This is the batching engine working exactly as intended.

    This is a complex technical part of the engine, please don't jump to conclusions or make assumptions about what the engine is or isn't doing.

  • The runtime provides the UV co-ordinates for the sprite sheets. That's how sprites draw the correct content.

  • 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:3elchon3]

    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:3elchon3]. 
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 [i]does[/i] 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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

    The screenshot you posted shows it swapping texture between draw calls, which is normal. After you export - or in C3's preview mode, which uses in-editor spritesheeting - a great deal of those texture calls will disappear, as it combines most of the images on to just a few spritesheet textures. So that particular case is unique to preview mode in C2, and does not happen after export or in C3 at all.

    Based on the fact very few people have ever noticed a performance difference between preview and export in C2, I'd say the overhead doesn't matter anyway.

    • Post link icon

    I always made it clear if we made our own build system we'd have to charge for it, and people still seemed to be in favour of that.

  • It's not implemented right now, I had the impression nobody used it. Do you use it a lot?

  • Not yet I'm afraid, but Apple are working on WebRTC for Safari which should allow remote preview to work.

    • Post link icon

    Why can't you offer a C3 as a downloadable perpetual

    I suppose you'd also still want to use the on-going services we provide such as the app build service, remote preview, multiplayer etc.? Those cost us money to keep running.

    Just to pre-empt the going in circles again, usually the next suggestion is "so make them separate services" - but the entire Construct 3 subscription is already less than a build system alone (PhoneGap Build)!

  • A 3D shader only works with unique texture images.

    That's not true - you just need to set the UV co-ordinates. It works the same as it does in 2D.

  • Question to Ashley: does Scirra use their own engine to develop larger games? If not, perhaps it would be a good idea to work on at least one larger project to see for yourselves if there exist any issues.

    As I said before, we've already seen these issues with the Construct 2 editor itself. It doesn't change much though, we still can't fix broken drivers.