> Salty!

>

For anyone who missed the context, Lamar was back posting accusations that we're a scam company. Was willing to reconsider his ban at end of beta but not anymore. He's permanently banned now, account and IP address.

FINALLY. Thank you.

Ashley

I'm happy to manage spritesheet images myself and all of the memory issues that may arise from it if it means no seams, which I emailed you about a couple months ago, and I ended up implementing image loading myself separate from C2's spritesheeting with no issues and lower memory requirements than I had before, though I think what you're suggesting with image limits on desktop PCs is not, generally, an issue in most desktop games. The best solution (from a dev perspective) is to allow users to create their own spritesheets, even if they have some position/rotation/scale/limitations to work properly with Construct. Put simply, other software does spritesheets better, and it'd be nice to be able to update a single spritesheet that can keep collision shapes instead of having to re-import a spritesheet, have C2 split it up, and then have to redefine proper collision for each sprite. Even though C2 supposedly creates "optimized" spritesheets, I haven't found that to be the case and to shrink file size, I tend to find myself running all exported PNGs through PNGGaunlet which can reduce the size even further, with some images compressing another 90%. Yes, I know this doesn't affect memory usage, but it is a missing optimization for size on disk and it can be a bit of a pain to have to do it after every export because C2 may create differently-organized spritesheets if any images have changed due to re-import or additional spritesheet images being generated if more content is added.

As for working exports: we're not really presented with much info on export, and I've had issues where one export works and another done minutes later (for testing) fails on startup (red loading bar, for example) doesn't work, even though I may not have made a single change in either C2 or to whatever nw.js version I'm exporting to. Believe me, if I could figure out a way to more clearly report that issue, I would do so in a second.

Also, while it's good you won't defend a 4yr-old blog post that isn't accurate, it'd be even better if you walked back claims that WebGL performance is equal to that of OpenGL/DirectX, because at just the base level of that claim, the idea that a graphics functionality wrapper on top of another graphics wrapper is as fast as a single graphics wrapper is...well, it's just silly.

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!

> ...

> 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.

>

+1000

I know, right? I've optimized the hell out of Sombrero (which developers are also encouraged against in Scirra blog posts, while those developers then receive the blame for poor game performance) and I'm 99% sure there is absolutely nothing I can do to improve performance farther, and the performance is nowhere near far more complex games, including other 2D games, because of some limitations that seem endemic to C2 more than general HTML5/JS/WebGL performance limitations.

> 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.

> I would say that getting this community more involved would be a great start. Conducting direct polls and really having a way for supporters to give feedback.

>

This has worked against us in the past. The multiplayer feature was massively voted for, but from the data we look at, very few people actually use it. So the hype effect is a big distorting factor in polls. I don't regret it, it was a super interesting project to work on, but it's something to bear in mind, and is the main reason I have avoided polls since then.

Having said that, we do have a feature-voting system planned anyway but I am going to strongly caveat it with warnings that "votes are not a guarantee of implementation", for exactly the reason we had with multiplayer. Also I can easily imagine things like 3D becoming #1 voted features, and there are a wide range of reasons why we're holding off on that.

There's a big difference between listening to all of your users - including those who haven't created a finished product in Construct - and those more "serious" (as the OP titled this thread) users who are looking for more quality-of-life features than anything new that will hardly be used by most users like multiplayer or unrealistic requests for 3D in a tool designed specifically for 2D. There's only a handful of more advanced C2 users because (I think) of some of the limitations in the engine that theoretically make features easier to use, but which annoy us more advanced users because we're hitting hard feature walls we can't work around like globally-shared images for tilemaps (if this was optional, it would be a heck of a lot easier to set up dynamically loading tilesheets and tilemaps), forced spritesheeting (which causes issues with seams, no matter how you spin in it, so it'd be nice to turn off for desktop builds where they provide little performance benefit), setting variable values without being forced to select the variable through a dropdown, real If statements (that also don't require using a dropdown for values or objects), etc.

lamar

> 1) You feel you were advertised the exporters instead of support of being able to publish to the platforms for Construct 2.

>

Just because it was advertised that it would work with the platform

*(with third party exporters)

doesn't mean they have to fully 100% support and make sure each platform's exporter works flawlessly with all features provided by Construct.

In fact Scirra has worked together with many of the wrapper projects to improve the project so Construct games can work even better in the environment but for each console the wrapper devs have to recreate the wheel and that needs a lot of time/skill/money. (Which is why it's good MS is doing their Xbox browser support stuff)

People didn't dev for Linux and Mac due to lack of support and we'd have a more stagnant dev environment if not for Valve and other companies throwing their weight into OpenGL/Vulkan to destroy the reliance on DirectX, but with consoles instead of just 1 environment (Linux/Unix-likes) you get multiple proprietary environments with not as wide of range of operating system/coding environment support.

I bet Scirra probably has some interesting stories trying to work with Nintendo if they were not under a NDA.

---

Now I do agree that there was a lack of support in regards to the exporters in terms of documentation that lead to additional confusions, as well as hopes that the parties making the wrappers would improve them more than they were.

As we see with Construct 3's cloud based service they're obviously getting an automated flow working to compile them for mobile, but I doubt the majority of the technology involved is Scirra proprietary. This means that it's possible for them to document majority of the process and then share with everyone so people can follow the steps and go through the process with their exported project.

No. If they're advertising platform support, that means the features of those platforms should work. Period.

What waits? It shouldn't wait at all - the UI should respond immediately.

It seems to delay right now. This was across multiple PCs I tried it on.

I can't believe people are still here having this convo after all this time. You can argue and point things out all you want, but it's not going to change anything. JayJay and I have learned from our mistakes and we've moved on. This is not and can not be a serious development tool (C2), and yes it was advertized as such and those of us who are serious devs have paid for the software and may not have gotten what we wanted out of it. That's life.

But you've blindly put your faith in something that isn't going to change, even after being told time and again that it won't. After being shown that your problems have fallen onto deaf ears. There have been enough signs to show people that if they really want to make a game and port it for that matter, this is not the tool to do it.

I love the editor to death, but the engine can't be taken seriously. And the bottom line is, it's not your engine to change and they don't have to do it.

If you don't like what it is, it's time to move along.

I think many of us have already moved on to using other tools, though we still hold out hope that Scirra will start listening to what's being said to them at some point because we like the idea of how Construct works, and we understand what's possible with that way of working. I know my favorite part is getting to skip a lot of the setting up of functionality, and other than that it just feels like any old game development tool, with (most of) the kind of features I'd expect.

People are stubborn, and the kind of people who gravitate towards both game development and tools for game development are, I think it's safe to say, never short in the stubbornness department. If Scirra were more straightforward and a bit more honest with both their marketing and themselves in relation to what their tools can actually do, this discussion would never have happened in the first place. But here we are, and even though some of us feel we've been sold a bill of goods that's yet to be delivered, we're still holding out hope. Which I would think is exactly the kind of passionate community any of us posting on the topic would kill to get for our games...if more people could play them.

digitalsoapbox

12 years of experience as Dev working in companies in Montreal is not experience enough? I'll be damn then.

I went through a long process of the whys I would need to change and even if it cost time = money still my best solution in the long run is to switch to another engine. Its simply a matter of risk and reward. Business are also made of that, it seems.

Then you understand that working as a developer isn't the same as being the person selling games commercially, correct? Or that when a company such as Scirra says their tool can do something, it should be able to do them, and not do them in the most half-assed way possible, if they actually do them in any way that is commercially viable at all?

> I don't understand why are you guys still talking about the Wii U since :

> 1- It didn't sell pretty well.

> 2- Everybody is talking about the Nintendo Switch.

>

> So It won't be any surprise if Nintendo decides to drop support of the Wii U next year.

>

> Scirra should be focusing on the Switch since most engines are preparing exporters for it.

>

Switch has no browser yet (available to the public at least) so we don't know how well it will/wont run.

However WiiU is still a valid audience, theres a lot of people with WiiU who won't upgrade to Switch any time soon. It's an audience starving for good games

It's not a valid audience for C2 developers, sadly. Somewhere upthread Ashley mentioned something about it "not supporting WebGL," which, like many statements Scirra makes, is only true in the vaguest sense. As Nintendo typically does, they rolled their own graphics acceleration solution that IS supported in NWF (pretty sure that's public info, so I'm comfortable saying it publicly). Scirra chose not to support it and went with their usual "this is non-standard so we won't support it" line of defense that I've never heard any other engine developer use because no product sticks 100% to the mythical idea of "standards" to succeed. I mean...C2 can't even move a single sprite across the screen smoothly on Wii U. That's not an issue with the console. That's an issue with the underlying engine technology.

Even if you do a research about x game engine, there's always bumps in the road. 2 years ago for a release in the previous studio I was working for, when Unity switched version to 5, a lot of plugins specially for rendering were broken in the process. There's always issues that you can expect and there's always a way or workarounds. In the case of engines like Unity and Unreal there's a reason why you can obtain source code now.

But to be honest, personally I don't see the issue, I mean, if Scirra can't offer export to consoles, then you change projects. In the world of indie dev you can't just stay with one product just because you are an artist and can't code. I'm an artist and yet I learned to code. Necessity pushes you to it, that's all. is not the first time a dev quits Scirra to change engine.

Slain which saw a major release was a C2 project and yet was forced to change to Unity. Engine was simply too limiting.

I...don't think you understand how game development works as a commercial interest. If you start working on your game in an engine that claims to have X features, and then after working on a project for a year or so it turns out that the claimed features are a total fabrication, you've just cost yourself potentially tens of thousands of dollars in lost time, not to mention sales revenue. You can't always just "change your products." Maybe if you're making games on the side or just for fun you can, sure. But not if you're developing commercial products.