Technical Question on WebGL Rendering

Discussion and feedback on Construct 2

Post » Tue Mar 25, 2014 12:26 pm

A quick overview of the WebGL renderer is this: (maybe this deserves a separate blog post)

1. As far as memory usage goes, the layout-by-layout loading means that on start of layout all textures that are used by the layout are loaded (and any others released). All frames of all animations of any objects initially placed on the layout are loaded. This means for the purposes of rendering a layout, loading/unloading textures can be ignored.

2. The WebGL renderer is a batched back-to-front renderer. This means it draws the bottom thing on the bottom layer and then moves to the front, drawing things over what's already been rendered.

3. The "batch primitives" include things like "set texture" and "draw N quads". C2 batches draw calls to eliminate redundant work. For example if the engine tries to set the same texture 3 times in a row, it only adds one "set texture" batch job.

4. If there are 10 of the same sprite showing the same texture, and they are all drawn in a row (so they must be consecutive in Z order), the batch can be just two items: "set texture" then "draw 10 quads".

5. If there are 10 of alternating sprite types with different textures, they cannot be batched with a single "draw 10 quads" call, because that can only use the same texture for all of them. So the batch ends up with "set texture A", "draw 1 quad", "set texture B", "draw 1 quad", "set texture A", "draw 1 quad"...
This is not as bad as it sounds. These are very quick calls and are still much faster than the equivalent canvas2d rendering commands.

6. After export there are lots of optimisations run like image deduplication and spritesheeting. This makes it more likely that objects share the same texture, so in some cases after exporting the batch can look like step 4 where it would have looked like step 5 in preview, which improves performance slightly.

So overall you can optimise your game by doing things like making sure objects with the same images appear consecutive in Z order. But this can be difficult, and is probably a "micro-optimisation" - there are likely to be much more important things to worry about for performance.

It's possible to make giant spritesheets that have all the game's images on it, but it doesn't totally eliminate texture switching if you have lots of images and exceed the maximum texture size with one spritesheet. Also putting all images in one image can make the loading bar useless in web games, and actually can significantly increase the download size (particularly problematic where stores have a file size limit, like Google Play). More info in this in the blog post Under the hood: spritesheets in Construct 2.
Scirra Founder
B
395
S
231
G
88
Posts: 24,367
Reputation: 193,684

Post » Tue Mar 25, 2014 5:35 pm

First: Definitely make this a blog post. This is very useful info, hate to have it get buried in the forum to never be seen again.

Anyway: Glad it's done by Z order rather than UID; makes more sense and easier to design around if need be. Thanks, @Ashley
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Wed Mar 26, 2014 12:39 am

I appreciate everyone's input and it's great to get some insight into what is happening under the hood with C2. That was a fantastic bit of information.

I guess though even with that information the situation doesn't change. Developers should take care and understand that putting 50 different objects that do the same thing, are single image sprites as say a jigsaw puzzle. Are actually working against the rendered.

Having done some research older devices such as iPhone4(not s) should only have apx 25 draw calls to maintain good performance. I think Ashley should certainly write the blog about draw calls, use of sprite sheets and a guide.

Ashley once said recently that one of the biggest reasons people have a hard time with mobile game dev; is because of GPU overload. I see this all time. Knowing that C2 treats every different object regardless of spritesheet optimization will still cause a separate draw call is good to know.

Of course mobile devices of 2013 easily have draw call of around 200+. Also It seems like modern computers have a relative safety around 1000 to 2000. But it seems people want to do 200 calls on older devices.

I found the discussion fascinating. Thanks. I'll continue to read up if more posts come.

batching sprites is good. Be smart about batching as an object over multiple 2048x2048 sheet's isn't that good.

Yes a well written technical blog would be fantastic on the subject and may help relieve the "mobile performance sucks" syndrome.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Wed Mar 26, 2014 8:16 pm

why not batch objects per family? or have batchgroups, this would provide more control over the batching, this would also batch single objects together, like for example the spriter plugin, there's no reason that these objects should not be batched together, and in the end would maximize performance for everyone, using frames or objects.
ImageImage
B
70
S
21
G
7
Posts: 827
Reputation: 10,052

Post » Thu Mar 27, 2014 12:59 am

@vtrix
oh my yes. once I learned more detailed information about this I realized that Spriter is never going to be mobile capable with C2 with any kind of complex spriter. I looked at the default platformer character; 43 objects. Considering that an 1g iPad should be around 100 for ideal performance that character alone uses almost half. Then add a monsters, fx and stuff. Spriter will blow over most mobile devices in a single breath.

I posted this request in the thread that Spriter should change to a single sprite object due to this. But I never got a reply. Spriter may not be mobile friendly until mid 2015. Which is a pity with all the work that went into JSON structure for better cross html devices.

Of course you can get away with simpler component spriters though.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Thu Mar 27, 2014 1:19 am

@jayderyu

You are severely underestimating draw calls of devices.

A modern computer can easily handle 30,000 draw calls. Something like an i5 CPU can handle 20,000+, i7 is more. This is from DX11 vs Mantle dev talks.
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,614

Post » Thu Mar 27, 2014 1:49 am

For those that come to the thread and missed the blog post:

www.scirra.com/.../how-the-construct-2-webgl-renderer-works
B
147
S
74
G
20
Posts: 1,786
Reputation: 22,527

Post » Thu Mar 27, 2014 11:01 pm

@Silverforce
Very true. however I'm not referring to technical limits. I'm referring to C2 safely ignore limits :D. In technical limits I've seen tech demo's produce mind boggling renderings. heck I remember each year where Sony/MS showed these fantastic renderings. However when we the games come up they aren't anywhere near the tech demo display. The reason this is because tech demo's are optimized to do one thing where as games need to be dynamic. You also likely won't find many games even around 10k at this time. If your running even near 10k then likely your spending more time keeping the game logic optimized :D

@alspal
Thank you. However this is the thread in question that is made at the beginning of the blog post :)

but I want to point out the blog point a key factor.
On one statement Ashley says there isn't any need to for optimization. And on another statement goes on explaining how Space blaster actually makes use of optimization. I think what matters is
Do layer and object based optimization, but don't obsess over it. Also keep in mind that Ashley wrote the engine and very likely has the best development structure in mind and habit already. Where as many C2 developers do not.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 10 guests