PC browser games only 5%,should Construct change?

Post » Sat Jun 24, 2017 12:44 am

TGeorgeMihai wrote:
Bob Thulfram wrote:Speaking of other markets, Construct 2 supported exports to Nintendo Wii U. I saw the same games on Nintendo 3DS (but they may not have been created in Construct 2). Does anyone know if the new Nintendo Switch supports games created in HTML5?

Could Construct 3 support games for the Nintendo Switch or 3DS? I assume no one is creating Wii U games. :lol:

Nintendo used "Nintendo Web Framework" (HTML5 games) in an attempt to bring more developers on Wii U.

While the Switch should be able to run HTML5 content and has a touchscreen, it already has a lot of developers (and support for Unity), so I think it will not get "Nintendo Web Framework" anytime soon (or at all).

Even the New 3DS is a no-go for HTML5 due to performance issues.


I'm not entirely surprised that Nintendo Web Frameworks was not carried over to N3DS or NS. Bummer!

Of course, even if someone could use NWF, jumping through the hoops to get the game accepted is another story. Sounds like Unity is the way to go for Nintendo games.

Speaking of Nintendo, Ever Oasis just came out for the 3DS, proving that the 3DS is not dead. And next week RPG Maker FES comes out for the 3DS. Awesome stuff.
Proud Construct 3 subscriber.
B
20
S
5
G
5
Posts: 205
Reputation: 4,614

Post » Sat Jun 24, 2017 1:10 am

Anyone who ever got their hands on the WiiU + dev kit had learned quickly that C2 games weren't going to run well on it (especially anything non-turn-based/action oriented) :(
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit
B
113
S
39
G
17
Posts: 2,184
Reputation: 19,217

Post » Sat Jun 24, 2017 12:24 pm

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. Many Construct users naively create a stack of 14 force-own-texture layers, causing every pixel to be written to at least 14 times, which absolutely hammers the GPU bandwidth for all it's worth. Then traditionally they blame HTML5, Construct, browsers etc. without recognising what they've done.

Part of this is the game design aspect: AAA games are built by experts who know this GPU performance stuff inside-out. If you're an indie dev just starting out with Construct, things like fillrate limitations are often things you learn about the hard way.

Jayjay wrote:I'd really like to recommend again that you use your own tool to make (and release/troubleshoot) a full sized platformer game (on at least Steam for Windows) and experience the issues that others like myself have reported here.

I do work with very large projects. Thanks to the developers sharing them, I do privately have C2 projects for games like Airscape and The Next Penelope. On the whole, they seemed to work fine, and the C2 engine was holding up great. 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. That is exactly what I was talking about above. So my view here is not due to naivety, it's actually based on working with these very large projects.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Sat Jun 24, 2017 1:51 pm

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. Many Construct users naively create a stack of 14 force-own-texture layers, causing every pixel to be written to at least 14 times, which absolutely hammers the GPU bandwidth for all it's worth. Then traditionally they blame HTML5, Construct, browsers etc. without recognising what they've done.

Part of this is the game design aspect: AAA games are built by experts who know this GPU performance stuff inside-out. If you're an indie dev just starting out with Construct, things like fillrate limitations are often things you learn about the hard way.

Jayjay wrote:I'd really like to recommend again that you use your own tool to make (and release/troubleshoot) a full sized platformer game (on at least Steam for Windows) and experience the issues that others like myself have reported here.

I do work with very large projects. Thanks to the developers sharing them, I do privately have C2 projects for games like Airscape and The Next Penelope. On the whole, they seemed to work fine, and the C2 engine was holding up great. 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. That is exactly what I was talking about above. So my view here is not due to naivety, it's actually based on working with these very large projects.

Thanks for the explanation

As i said, it was not a dig at Construct, it's just something i've wondered about due to my own ignorance on the subject
B
15
S
3
G
1
Posts: 91
Reputation: 1,664

Post » Mon Jun 26, 2017 6:27 am

Ashley wrote: Many Construct users naively create a stack of 14 force-own-texture layers, causing every pixel to be written to at least 14 times, which absolutely hammers the GPU bandwidth for all it's worth.


Can you explain this a little more? Just want to make sure i'm not doing the exact same thing already too.
B
81
S
26
G
9
Posts: 244
Reputation: 10,616

Post » Mon Jun 26, 2017 2:36 pm

Ashley wrote:If you think Construct 2 can't handle graphically intensive games, then as ever, rendering is bottlenecked on the GPU. So if you switch tool because of that, the hardware isn't going to be any faster, and the performance won't be any better.

I think some people switching tools have hardware-bottlenecked games and are eventually going to realise it was never C2's fault. I do see a lot of games bottlenecked on the GPU, and everyone knee-jerk blames C2, HTML5, Chrome, or anyone or anything else. I don't know why it's so hard for people to believe they've fully utilised the hardware? The engine is designed to let you do just that. I'm happy to be proven wrong, please send me your projects and all that, but it usually only confirms the point. I imagine some people will wander from tool to tool always thinking everyone's engine is awfully slow, never recognising that hardware is a limited resource.

Just to pre-empt how this discussion usually goes: now someone's going to shift the goalposts and talk about some random bug or some quirk that we fixed, or some other problem they had at some point, or start listing their personal laundry list of things they want changed. That has nothing to do with GPU performance. On this specific point, C2 is as good as a native engine, and I stand by that.



I shouldn't be running into bottlenecks on a 970. Or a 1070. Even the low-end target of a 750 (which should be lower, but can't be because of issues with C2) for Sombrero. If I'm running into fillrate issues in C2, that I don't run into elsewhere? That's a C2 issue. Period. Maybe the F2B renderer would have helped, but it was abandoned quickly and hasn't been brought up since. No point in waffling about on it - C2 is slower than the competition in getting things on screen. The reasons aren't especially relevant in the end.

So, no. No shifting goalposts. C2 simply isn't as fast as native, or whatever you want to call what other tools are doing. This is aside from issues with getting games running on as many of the platforms people buy games on as possible, which is also less of an issue with other engines, aside from the frankly embarrassing "support" for the Wii U, which was anything but, or the longstanding (years?) mentions of XBox One support that are still nowhere to be seen in terms of actually being able to RELEASE a game on the platform, with the features gamers expect. If I had to hazard a guess, we may end up relying on third-party support for that platform as well, much like Steam4C2 is much better than the support Scirra provides for Steam features, despite both being based on Greenworks.

I'm not talking about issues with HTML5, either; I'm talking about C2 specifically, and I suppose C3 considering it's basically just C2 with a different IDE, higher costs, more complex plugin development, and less flexibility for developers to do their own local builds with their own toolchains for NWjs on desktop & mobile.

You'd think that every dev that's made anything of scale in Construct having to move on to other game creation tools would be enough of a hint, but stand by your point as much as you'd like I suppose. The people buying games don't care about a game's tech, as long as it works as expected and provides good performance. It doesn't matter how easy C2 may be to use to make games if they have far higher hardware requirements, and are limited to less platforms than similar games based on different tech, limiting their market.

Jayjay wrote:Anyone who ever got their hands on the WiiU + dev kit had learned quickly that C2 games weren't going to run well on it (especially anything non-turn-based/action oriented) :(


@Jayjay
If memory serves, since I've long ago returned my WiiU devkit, this was due to Scirra's stubborn refusal to support the way the Nintendo Web Framework handled hardware acceleration, which was available for HTML5-based games. And didn't a third party actually have to finish implementing the framework, since what Scirra provided was the bare minimum of feature support, and not what NWF was capable of, even outside of hardware acceleration?
Last edited by digitalsoapbox on Mon Jun 26, 2017 4:32 pm, edited 10 times in total.
B
70
S
40
G
24
Posts: 518
Reputation: 20,070

Post » Mon Jun 26, 2017 2:44 pm

The biggest bottleneck I've seen is from going fullscreen with too much content.
Image ImageImage
B
168
S
50
G
163
Posts: 8,226
Reputation: 105,071

Post » Mon Jun 26, 2017 3:30 pm

Ashley wrote:So my view here is not due to naivety, it's actually based on working with these very large projects.


Only two projects?
There you go, there can be no other problems. It is always user error.
:roll:
B
29
S
14
G
9
Posts: 80
Reputation: 5,993

Post » Mon Jun 26, 2017 4:10 pm

All I know is that c3 keeps running out of memory whenever I'm trying to preview my games. Those same games run just fine in c2. And needing to do things like download and use Canary is annoying when I should be able to just run c3 and it work.

I honestly feel like I just paid to beta test c3 which is not a good feeling at all.
Image
B
69
S
19
G
9
Posts: 548
Reputation: 13,710

Post » Mon Jun 26, 2017 4:20 pm

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
B
29
S
14
G
9
Posts: 80
Reputation: 5,993

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 2 guests