PC browser games only 5%,should Construct change?

Post » Tue Jun 27, 2017 9:30 am

digitalsoapbox wrote:I shouldn't be running into bottlenecks on a 970. Or a 1070.

Those cards have insane amounts of bandwidth. So it's unlikely to be fillrate. So you probably have a CPU-bound game. So you can then use tools like the profiler to investigate why that is and optimise your events.

So no, still nothing to do with rendering performance.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Post » Wed Jun 28, 2017 4:49 am

Ashley wrote: The Next Penelope in particular had some issues with using too much fillrate early on, but Aurelien made some game design changes to reduce excessive layers, effects etc. and then it fit much better within GPU hardware limitations.


Has there been more details about this posted somewhere? I'd be keen to learn from their mistakes so I don't repeat them, incase they've encountered things I hadn't thought about. Obviously you've clarified to avoid using "force own texture" at least, and to minimize effects as often as possible, but what's meant by excessive layers is unclear.
B
151
S
75
G
20
Posts: 1,793
Reputation: 22,749

Post » Wed Jun 28, 2017 7:37 am

It is a problem designing and marketing a product for non programers and the like yet expecting them to know all about fillrates and things.
B
43
S
23
G
21
Posts: 735
Reputation: 12,132

Post » Wed Jun 28, 2017 11:23 am

We probably do need dedicated documentation on this, but the basic principle is simple enough: if you have 3 sprites stacked on top of each other, then each pixel is drawn to 3 times, because C2 renders back-to-front. That's overdraw (filling pixels more than once), and it wastes fillrate. Using a force-own-texture layer (which includes options like opacity which implicitly turn it on) causes the entire layer to be overdrawn since it has to draw the layer's own texture to the screen.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Post » Wed Jun 28, 2017 2:52 pm

Ashley wrote:We probably do need dedicated documentation on this...

I would like to see that happen, I would like to read in depth article/documentation about fill rate, back to front, front to back, how Construct 2/3 deals with fill rate and about tips how to get max performance with minimum sacrification.

As I see it now: Construct is back-to-front, so opaque object won't prevent rendering the objects behind it.
"Force own texture" is a fillrate-greedy option that should be avoided if possible.
Having many layers is not a bad unless you forcing them own textures.
Nothing is rendered outside the canvas borders.

Correct me if I'm wrong.
B
62
S
32
G
6
Posts: 125
Reputation: 7,975

Post » Wed Jun 28, 2017 2:53 pm

Ashley wrote:We probably do need dedicated documentation on this..

That's a great idea, just please include it in the manual because tutorials and blog posts get lost/forgotten over time.
B
135
S
33
G
17
Posts: 1,557
Reputation: 20,721

Post » Thu Jun 29, 2017 10:33 am

3DPiper wrote:How hard would it be to add a 'GPU bandwidth gauge' to warn the user there will be GPU bottlenecks....?
If this is almost always the main performance problem and the users aren't aware of it, a system to automatically check and warn the user might be very helpful


This is a great idea! Similar to several music programs I use, I want to know when I am pushing the GPU meter into the red. It is sounding like the performance issues relate to GPU.

And ... overlapping textures?
Proud Construct 3 subscriber.
B
23
S
5
G
5
Posts: 207
Reputation: 4,693

Post » Thu Jun 29, 2017 11:04 am

Ashley wrote:
jn2002dk wrote:I have a hard time understanding how Asphalt 8, Modern Combat, Titan Quest etc. can all run on my device yet somehow a simple 2D game is maxing it out

3D games in particular have a very different rendering approach. Many GPUs have limited bandwidth, and the fact 3D games have depth allow them to use a front-to-back approach that more or less ensures every pixel is only drawn to once, at least for the basic color pass.


@Ashley

Thank you for pointing this out. Using the Q3D plugin with C2 to make 3D games, I have wondered why I have been CPU-limited instead of GPU-limited, even though there are potentially many occluded surfaces for every screen pixel. Using the integrated Intel graphics on my 2013 MacBook Air, I have not even begun to stress my GPU, while I have been way overloading the CPU. I have had to go through every event sheet with a fine-toothed comb to minimize CPU cycles.

In 3D games, I have been using small textures, and the GPU has never been a bottleneck.

Just for kicks I have been tooling around with Unreal Engine 4 and Unity for the past few weeks. Unreal Engine 4 crashes every 15 minutes, completely overwhelming both my GPU and CPU. Unity is stable, but I don't try to push it. Three.js (a webGL 3D framework) is totally stable on my MacBook Air. After experimenting with all of these options, I concur that WebGL doesn't have a fundamental disadvantage for GPU-limited games. We still need to be careful about the CPU though. I think there is still a native performance advantage for CPU-limited games.
www.simbucket.com - HTML5 Science Simulations / https://www.airconsole.com/#!play=com.n ... obotrumble - Robot Rumble on AirConsole
B
50
S
15
G
25
Posts: 424
Reputation: 17,296

Post » Thu Jun 29, 2017 4:53 pm

glerikud wrote:
Ashley wrote:We probably do need dedicated documentation on this..

That's a great idea, just please include it in the manual because tutorials and blog posts get lost/forgotten over time.


I would like to understand this better too. Please create some documentation on it.
B
16
S
7
Posts: 190
Reputation: 1,823

Post » Thu Jun 29, 2017 7:44 pm

The basic idea is add stuff till it stops working.
That's when you know the limit.
Thats why its good to develop on a slow machine.
Image ImageImage
B
170
S
50
G
179
Posts: 8,378
Reputation: 113,425

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest