Concerns from a "Serious" developer

1) What exporters are missing from C2? They all work. Some work better than others; none of them are broken.

Have you any games with paid customers / mass publishing ? A lot of the users bringing their complaints here do, or have tried to reach platforms that C2 promised them and failed (WiiU in particular)

"Some work better than others; none of them are broken" is not valid for this audience, and the phrasing suggests that merely being able to export is the end goal of the Construct workflow.

However, I propose a radical opposition to this: The games should work.

Customers can't tell when an exporter has worked properly or not, they can tell when a game is unplayable.

Producing unplayable games is not the interest of commercial developers.

Scirra needs to come out and say "This isn't meant for you" to commercial developers if they aren't going to be expected to have 100% export and functionality to the platforms they list on their advertising.

Or, they need to at least list the side-effects of export to each platform like a medical commercial.

>

> > Do you want us to build native engines? I've covered that in this blog with our rationale around that, which nobody ever really directly argues against, there's just vague accusations of how HTML5 is "poorly optimised" or something, which really is not the case given the potency of modern JIT compilers and the native-equivalent performance of WebGL.

> >

>

> Actually I and others do have a problem with the arguments in that article, as well as the article on "HTML5 games faster than native"

>

> Let's see:

>

>

> > WebGL is close enough to OpenGL to be considered the same performance-wise. In other words, Construct 2 games render in practically the same manner a native engine would.

> >

> > ...

> >

> > We already cover Xbox One and Wii U - so that only leaves PS4. Currently we're blocked by Sony not providing an easy way to publish HTML5 games to the PS4. Given how well our Xbox One support worked - requiring no significant changes to our engine to work on a console - we are keen to see Sony supporting HTML5 on their console too.

> >

> >

>

> There's a few arguments against those lines of thought:

>

>

> > Listing GPU fillrate as the main cause of a games slowdown... and then stating that the WiiU is a viable export platform is quite funny. WiiU doesn't support WebGL, meaning not only regular GPU "fillrate issues", but no special FX and low performance.

> >

> > 5FPS after losing WebGL and FX is still not playable for a platformer. We didn't even make an HD title, just a retro 16bit platformer with 32x32 to 64x64 pixel sprites on average.

> >

> > As for fillrate being "the main culprit", there are many instances where CPU should be considered too (eg: most enemies and players using the platformer behavior) and, no matter the optimizations, aren't going to be able to combat the issues of JavaScript without emscripten. But, if you make a tool that exports to HTML5 through emscripten it might as well also export the actual C/Cpp (to port to the JS, best of both worlds).

> >

>

>

> > Even the mobile games developed with Unity and Unreal put C2 at the ground... How you can even compare?

> >

> > - Native games is WAY better in lower and mid hardwares, and this is AMAZING because more people will play your games.

> > ->>Scirra depending on thirdy-partys for realese our game. Remember when you guys drop support to Cocoon as exporter? That's why I droped C2.

> >

> > ...

> >

> > By the way, The Next Penelope is being ported to C ...

> >

>

>

> > To me the main issue I had with html5 games is that on low-end devices (iPad 2) they perform not really well at all. The same simple app on iOS, even with the super accelerated safari, tends to have small hickups and feels not smooth compared to the same done in a native engine (love2d in this case).

> > The situation seems a bit better on newer devices (iPhone6), but still showing those small jerks every now and then (are they GC related?).

> >

> > All of this scares me away from trying to do something serious with html5 engine.

> >

>

>

> > While it's true most devices support webgl it doesn't mean we get the same performance as native in that respect. In my experience it varies per device, and it's just not about the hardware capabilities. Case in point, for me in CC rendering is way faster than in C2. This goes against your benchmarks so that leads me to believe webgl gives native performance on only certain devices. The argument that the hardware is the limit doesn't fly when changing software and doing the same thing performs a lot better.

> >

> > The browser's hardware support is primarily about having everything work instead of having everything have good performance imo. Even things like the vsync jank is still there on some hardware. This is probably what causes the disparity between the issues users see and what is tested.

> >

> > I don't know if native support would fix this, and I realize doing so would cause a load of different issues and multiple code bases, but there seem to be core issues with how browsers do things that are not performant.

> >

>

> Now, in regards to "HTML5 faster than Native?":

>

>

> > Construct 2's WebGL renderer is faster than our previous native C++ DirectX 9 based engine - the one we developed for Construct Classic.

> >

>

> This is a completely wrong comparison, because C2 is largely an improvement and optimization on CC, you already learned from past mistakes and found new ways to optimize. It's the software form of a "straw man" argument against native.

>

> If you back-ported those optimizations back to C++ you'd find that the results suddenly return to native being the fastest and smoothest. We can tell this ourselves from simply our experience of porting to Unity in C# with our current game and seeing it run much faster and with more lighting, special effects, and enemies on-screen than our C2 prototype.

>

> Then there's also the people who didn't see the results that are promised in that article with C2 vs CC:

>

>

> > 97151 - WebGL

> > 128458 - Native

> > i3 - 3220 / GeForce GTX 550ti with small factory overclock / Win 7 64 / nvidia driver 306.97 / 8Gb RAM

> >

>

>

> > Intel E2180 2Ghz, 4GB RAM, Win7 64 bit, SP1, Geforce 210, Nvidia 306.97 driver

> >

> > Native/DX 25613

> >

> > WebGL:

> > Chrome 22: 3801

> > Chrome 23: 4482

> > Chrome 24: 3901 (dev)

> > Chrome 25: 3503 (chanary)

> > FF16: 3254

> >

>

>

> > i7 9203.6ghz, 48gb, win7 64bit , amd7970 3gb, catalyst 12.11(beta)

> >

> > Native/dx: 118040

> >

> > WebGL:

> > Firefox 16.0.2: 58712

> > Chrome 22: 103761

> >

>

>

> > WebGL Performance (Google Chrome 23): about 10400 objects

> > Native Performance: about 24000 objects

> >

> > My notebook: Processor Intel Core i5-2410M 2.3 Ghz, 8 GB Ram, Graphic card Intel HD Graphics 3000, OS Windows 7 Ultimate 64-Bits

> >

>

> I'd like to point out two things from all of this:

>

> 1.) Like the data above, some of the "still-Steam-average" hardware still sees native far out-performing WebGL, and desktop is currently the best supported platform for HTML5 + WebGL. The results may be 4 years old, but the average 2D gamer (based on customer support issues on Steam) hasn't updated their PC/laptop/even just the graphics card in a long time.

>

> Even with an Intel i7 6700k and GTX 1070 which has much better WebGL support than most of my customers I get:

>

> Sprites/objects >= 60fps with no drops below

> Native/dx: 86k

> Chrome: 95k

>

> This may not be the number of sprites that will appear in a game, but it still reflects an underlying performance gap between Construct Classic (which could be argued to be almost as un-optimized as C2 is optimized) and WebGL. HTML5 is not faster than native. It can get close with WebGL + Emscripten, but it inherently is just not capable of being as fast as native, and I wish that Scirra would stop trying to compare the two this way.

>

> 2.) You can't just ignore comments/evidence/arguments against your company/public statements about your engine and then claim "nobody ever really directly argues against" them!

>

> Bonus: That multiplayer plugin would probably have been used a lot more if people were able to export their games and "publish everywhere". It's also possible the users are waiting for more helper functions/plugins/behaviours that make tracking objects much easier (Eg: a behaviour for syncing objects). I know multiplayer is generally a hard feature, but it's a great one to have even if it doesn't get used as often as other plugins.

>

> Like others are saying, yes, export matters 100% more, but I still am glad Construct got multiplayer.

>

> Although, it seems some other users had a better time using their own multiplayer solutions:

>

>

> > Using Electron instead of nw.js made my games smaller and better working, using my own networking solution with central socket.io based server destroyed weird, random connection problems that disallowed me from even testing my game. And made multiplayer a lot smoother. Being able to write my own rendering code allowed me for much more control over how stuff is shown on screen what makes performance better.

> >

>

+1 to all of this, especially the "we're just as fast/faster than native" claims which are so completely beyond the pale in terms of just outright fabrications of HTML5's current abilities, using C2 or not. This is something I knew going in to C2, and I understand the performance difference (though it is greater than it should be with C2), so when I see this claim pushed over and over despite gallons of real-world evidence otherwise - and sorry, but your internal tests with tiny little games or demos mean nothing when compared to thousands of copies of commercial games out in the real world that show the opposite, and PLEASE don't try to blame the game's developers for this as you've done in the past - it's very hard to swallow after the 100th time when all evidence points to the opposite being true.

+1

Events can be abused way easier than code, and even the templates that come with C2 aren't designed for performance necessarily.

There's dozens of different ways to do things, and many of those are just terrible for performance.

I'm telling you there needs to be some exposition into the proper use of them.

You make a "for each object" that runs every tick, then the exporter should give a warning, etc.

Events can be abused way easier than code, and even the templates that come with C2 aren't designed for performance necessarily.

There's dozens of different ways to do things, and many of those are just terrible for performance.

I'm telling you there needs to be some exposition into the proper use of them.

You make a "for each object" that runs every tick, then the exporter should give a warning, etc.

Most of us that have used Construct 2 for a long time and have done the leg work already know this and optimize our games, and avoid poor event practices--so this has nothing to do with this post.

Events can be abused way easier than code, and even the templates that come with C2 aren't designed for performance necessarily.

There's dozens of different ways to do things, and many of those are just terrible for performance.

I'm telling you there needs to be some exposition into the proper use of them.

You make a "for each object" that runs every tick, then the exporter should give a warning, etc.

Have to agree with that being a useful feature, plus it means that instead of users finding work-arounds to issues like families (eg: often needing a for each object to actually let each object in a family do what it's supposed to individually) then the users would be forced to submit bug reports to issues and improve Construct for all.

Although I also agree with jayrp1 because the users here are probably seasoned in the tool and have done whatever it takes to save performance already.

Wow, a 22 pages long topic. While it was an interesting read, I have to admit that after 12 pages or so I had to just scroll though the pages, since it takes ages for me to read all posts through (hats of to those who do that). But one think caught my eye and I'd like to tag Ashley for I think it's a great suggestion:

A page with Scirra tested benchmarks for each platform

(PC/Mac/Linux with PC specs, Android/iOS with model, wrapper vs browser

) with a Construct 2/3 version of the exported test file would work wonders in giving people an idea of how relative their current devices are to the test devices. If the benchmark demos even had an option to "submit your results to Scirra!" on it that would help aggregate consumer side data for a wider range of devices than the ones you can afford

(but I do recommend having an official list of test devices that you can have physically)

1) What exporters are missing from C2? They all work. Some work better than others; none of them are broken.

would it be a stretch to say that you haven't published or tried to publish a commercial game using c2? Because seriously, if you did, you'd know exactly what we're talking about.

We've spoken up about what the issues are plenty of times. Yes, the exporters "work." But that's it. That's like saying Photoshop does export PNGs, yet the image quality is low and the image is blurry... It DID produce a PNG though...

When we are here trying to get better exporters done, it's not going against anyone else's wants or needs so I'm not sure why there's so much backlash for asking for the exporters to work properly. We want our 2d games to work. They're 2d! I don't think it's too much to ask them to run as intended.

To be fair, since my post that jayjay quoted me with I have since got a replacement for my 10 year old computer so the graphics are no longer a bottleneck on my system. Also the few times I tried mobile export the performance was much better than my old system.

That would be great if Construct would use Electron instead of NW.js

And would add support to circular shaped objects (Shadow Cast and Collision) as well as fix the bug that would occur when the light is close to the object casting infinite shadow.

>

>

> 1) What exporters are missing from C2? They all work. Some work better than others; none of them are broken.

>

>

>

would it be a stretch to say that you haven't published or tried to publish a commercial game using c2? Because seriously, if you did, you'd know exactly what we're talking about.

We've spoken up about what the issues are plenty of times. Yes, the exporters "work." But that's it. That's like saying Photoshop does export PNGs, yet the image quality is low and the image is blurry... It DID produce a PNG though...

When we are here trying to get better exporters done, it's not going against anyone else's wants or needs so I'm not sure why there's so much backlash for asking for the exporters to work properly. We want our 2d games to work. They're 2d! I don't think it's too much to ask them to run as intended.

+1

Excellent analogy.

I was appealing to the letter of the law, as Lamar seems to be working on a false advertising angle.

I don't doubt C2 is immensely frustrating to use for console games; I use it for web projects and mobile games because I believe that is what the software is truly suited for.

To continue with your image editor example, Paint can produce the Mona Lisa, it's not inaccurate to claim this - yet if I was to try, I'd rather use Photoshop, because that tool is correctly suited for the job.

If I was to make a console game, I would personally use Unity, because I feel that HTML5 is not the right fit for consoles yet; and won't be until browser technology is considered as important as native - which is coming, slowly but surely.

I honestly believe the exporters work perfectly; it's the support for the underlying technology that is flawed.

Now where I do have immense sympathy for you is how Scirra advertise their export support. C2 can theoretically make websites; yet they (rightly) don't advertise it as a web editor - could one argue that this is similar to the WiiU? Perhaps.

To be fair, since my post that jayjay quoted me with I have since got a replacement for my 10 year old computer so the graphics are no longer a bottleneck on my system. Also the few times I tried mobile export the performance was much better than my old system.

Great point R0J0, although the Steam hardware survey says that's not the norm with only half the systems running Win 10+ (almost 30% still running Win7 systems) and only half are quad-cores on all of Steam.

From a commercial perspective, a 2D game that requires a quad-core CPU and latest line of NVIDIA or AMD or *maybe* Intel isn't very acceptable to the developers or their customers, and it reflects in Steam reviews and comments across other forums.

However, I propose a radical opposition to this: The games should work.

Customers can't tell when an exporter has worked properly or not, they can tell when a game is unplayable.

Producing unplayable games is not the interest of commercial developers.

Scirra needs to come out and say "This isn't meant for you" to commercial developers if they aren't going to be expected to have 100% export and functionality to the platforms they list on their advertising.

Or, they need to at least list the side-effects of export to each platform like a medical commercial.

Working exports? Clear communication and honest advertising?

Inconceivable!

To be fair, since my post that jayjay quoted me with I have since got a replacement for my 10 year old computer so the graphics are no longer a bottleneck on my system. Also the few times I tried mobile export the performance was much better than my old system.

What sort of performance/fps increase are you getting in compared to your old system?

lamar - you have previously ignored my replies and repeated the same question, and you're doing it again, so I don't feel like it would be constructive to reply.

Is there c2 plugin support for in c3?

We covered this.

[quote:2u18tg45]some kind or even access to the cloud exporters (or whatever is going on with c3) could be extended to c2 devs

We also covered this.

[quote:2u18tg45]I have to agree that Scirra is all about the waiting, wait for this feature, wait for this announcment

We just released the public beta of a major new product. This is not vaporware.

Was implementing multiplayer really a waste of time though?

From a business point of view, I think so, yes. We could have spent that time working on something else which people want more (and as always there's a lot to choose from). It took several months to implement, and back then it was just me, so it was more or less "stop everything and do this". Several months of development holding back everything else is a very costly thing to do for a small startup, and overall I don't think it was worth it. Like I say I don't personally regret it since it was super interesting, and I think to some extent it's good for marketing since people like to see the option is there, even if they don't really properly use it. But maybe we could have averted some of today's concerns if we'd put that much effort in to something else. And in that sense, the fact a ton of people voted for multiplayer and then we went and did it, caused damage to the business. So I do have some concerns about bringing this whole voting idea back, but hopefully we can manage that.

Now, in regards to "HTML5 faster than Native?"

I'm not going to defend a 4 year old blog post. Yes, it's probably wrong. It was just an interesting benchmark result. I haven't spent the past 4 years claiming HTML5 games are faster than native. Just that they're fast enough. It is basically fair and correct to say WebGL has identical GPU rendering performance to native code.

[quote:2u18tg45]A page with Scirra tested benchmarks for each platform(PC/Mac/Linux with PC specs, Android/iOS with model, wrapper vs browser) with a Construct 2/3 version of the exported test file would work wonders in giving people an idea of how relative their current devices are to the test devices.

We already ship some in Construct 3, in the tech demos section.

That would be great if Construct would use Electron instead of NW.js

They're the same browser engine, so this would not materially change anything.

Working exports?

Can you point to any specific bug reports so I can look in to the actual issues you're talking about? I'm honestly struggling to figure out precisely what anyone's talking about. There's a lot of vague references. Also some suggestions won't actually help. For example if you turn off spritesheets you'll run in to OS max image limits faster, which would probably break large NW.js games. So when you suggest turning off spritesheets, I think that would cause more problems than it would solve. A lot of the feedback here is like that. Nothing is as simple as it seems, really. It's all tradeoffs.

If everyone can slow down a bit, I can probably address everyone's points in more detail. This thread is literally dumping hundreds of posts with all sorts of mixed and varied concerns in the space of just a couple of days. I really don't like megathreads, I would encourage everyone to please start separate threads per single concern, and stay on topic in those threads, and then I may be better able to comment in a more focused way. (Again, I do think it's a pretty unique thing that you actually can talk directly to the founder, but I'm starting to see the appeal in disappearing behind a corporate team page...)