Native Desktop Exporter for Construct 3

Discussion and feedback on Construct 2

Post » Wed Jan 28, 2015 2:19 pm

C3 will be what it will be, and I do not think we have a choice in that, nor they have any obligation at all, if C3 is an "upgrade to C2" and that does not convince you, just do not buy it, ashley choice for C2 was html5 only, and while some people see it as a bad choice, they are native engines so buying an html5 one is not something you should have done, ok, there are hiccups in the marketing, but for C3, there should be not the same confusion.


I don't see why you're talking about people complaining about HTML5 here. Personally I have no problem with HTML5, it lets me create games and that's all that matters to me. I just don't see the point in making Construct 3 another HTML5 engine since there's already Construct 2 for that, even if it is going to have major changes, put it in an update, I'd hate to see our purchases rendered moot.

when in fact you trade off performance for portability and probably reliability. By far, the best solution is to improve C2's engine to resolve any performance deficiencies.


Currently, I don't see any of the games on the Construct 2 front page being made for anything other than PC, with the exception of 'Mortar Mellon'. You can improve C2's engine to resolve all the performance deficiencies all you like, if wrappers like Node-Webkit just release more broken builds like with the jank that's still not fully resolved, that will leave us with a perfectly fine and amazing engine that cannot export any normally functioning games due to non-Scirra companies releasing broken software or possibly even abandoning it.

@Ashley, I want to ask you a serious question. What would you have done if, after Google release the Node-Webkit with the jank and all the horrible performance, they shut down and stopped making new Node-Webkit builds and fixes?
We would be left with a broken exporter and basically all C2 users who want to export to computers would be furious, then you'd be forced to make a native exporter either way. We all know how many posts and a couple bug reports were made on just that one "update", imagine if that build was the last we got forever.

I know it didn't happen, but what if it did?
There is a thing as future proofing. In fact, if there was a native Construct 2 .exe exporter or similar, C2 users themselves could probably provide fixes for it just as they provide plugins and effects for the engine.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Wed Jan 28, 2015 2:37 pm

Construct 2 is great HTML5 game maker, but it gives 0% certainty that your game will work smooth on desktop or mobile. And if you will complain you will hear some random words about waiting for better future, upvoting bug reports and so on. Chromium/Node-Webkit/Crosswalk issues are the best examples. And that's why C2 is just a nice toy for newbies and education projects in primary schools.
Last edited by szymek on Wed Jan 28, 2015 2:42 pm, edited 1 time in total.
B
18
S
7
G
1
Posts: 783
Reputation: 4,237

Post » Wed Jan 28, 2015 2:42 pm

Ashley wrote:
PixelRebirth wrote:Webgl effects

...are run by the GPU and are no faster in a native engine...

instance creation/destruction

In this kind of discussion I always repeatedly ask for demonstrations of anything which needs optimising. This kind of thing can be improved, but instead of people showing examples and giving me the opportunity to improve it, they just demand a completely new native engine instead. Can you come up with an example showing some kind of performance problem here so I can profile it and do any necessary optimisation work?

as well as resizing/scaling

That is also run by the GPU and no faster in a native engine.


I'm sure you are very right about what you are saying in theory here.

However a simple test that creates a sprite with semitransparency at a random angle every tick, which also grows every tick by the factor 1.1 is already down to 30fps for my system when it reaches about 1000 instances. Using the very same sprite and the equivalent events in Classic runs still at a steady 60 fps with 1000 instances and beyond.

I'm not going to hide the fact that my observations are just that, coming from every day use. I didn't scientificly look into the issues to be clear. ;)

Ashley wrote:I find this frustrating because this is always the pattern with people asking for a native engine: they talk about performance problems without showing anything I can investigate, and then assume everything will be perfect when in fact you trade off performance for portability and probably reliability. By far, the best solution is to improve C2's engine to resolve any performance deficiencies. That to me is obviously at least worth significant effort before deciding it's hopeless and writing a native port. But we are a long way from determining that it is hopeless, and nobody is showing me any evidence to work with either, so what can I do? We're not about to rewrite our engine five times over in native tech based on a hunch.


It is far from my intentions to frustrate you in any way. I do appreciate that you weighed in and replied multiple times in this thread. Please keep in mind that I specifically stated in this very thread that I'm NOT asking a native exporter of Scirra.

What I didn't specifically state though (not in this thread anyway) is the trouble with relying on third parties in general. However others did repeatedly. So yeah, I was merely saying something along the lines of "Wouldn't it be cool if someone made a native Windows exporter?!". And then it blew a little bit up.

What I really got from this though is an ever increasing interest in asm.js.
B
22
S
6
G
10
Posts: 1,034
Reputation: 7,514

Post » Wed Jan 28, 2015 2:49 pm

Gotta agree that Classic was WAY more efficient when it came to sprites - you could easily have, like, 60000 of them bad boys on screen with no slowdown - C2 doesn't come close. So it is a little strange to hear how the playing field is basically level for both of them.
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Wed Jan 28, 2015 3:00 pm

Image ImageImage
B
168
S
50
G
169
Posts: 8,280
Reputation: 108,189

Post » Wed Jan 28, 2015 3:20 pm

Jayjay wrote:The Z-sorting on C2 was definitely much slower than CC and so I've stopped using it

I would love to fix this or improve it if possible, but again, I need an example of it.

Also with Node-Webkit: We're having issues with changing resolution and monitor refresh rates in-game

What issues, specifically? Have you filed bugs for them? We don't officially support any way to actually change the monitor resolution by the way.

Nesteris wrote:You can improve C2's engine to resolve all the performance deficiencies all you like, if wrappers like Node-Webkit just release more broken builds like with the jank that's still not fully resolved...

I'd point out that this is one bug in the 0.11.x version of Node-Webkit, it should already be improved in the 0.12 alpha which I posted to the forum recently. The main problem is that we did not previously have any way to roll back node-webkit updates, and due to changes to the exporter we can't support versions older than 0.11.x in the current version of C2. The timing of this bug badly coincided with the changes we made to C2, so everyone was stuck with that version.

Anyway, I guess this is a little overdue, but our NW.js download page now lists older versions:
https://www.scirra.com/nwjs

So this won't happen again. You won't have to be stuck with the latest version of NW.js only. If there's a problem you'll be able to roll back to an older version.

What would you have done if, after Google release the Node-Webkit with the jank and all the horrible performance, they shut down and stopped making new Node-Webkit builds and fixes?

We'd hire someone to continue development. But as far as I can tell, the NW.js project is getting stronger with a bigger community.

Somebody wrote:Gotta agree that Classic was WAY more efficient when it came to sprites

I still see no .capx files here. C2 has algorithmic optimisations that CC never had, such as collision cells and render cells, so it should in fact be able to scale to large games much more efficiently than CC could. For example with a huge level doing lots of collision tests, CC would just brute force its way through millions of collision tests, but C2 is much smarter and can cut out 95%+ of the tests by arranging objects in to collision cells. On a large scale, algorithmic efficiency is more important than absolute efficiency. Oh, and in the past we have actually measured Chrome outperforming Construct Classic, which I think now is due to Chrome's parallel & multi-process rendering architecture, whereas Classic was always single-thread single-process.
Scirra Founder
B
395
S
231
G
88
Posts: 24,367
Reputation: 193,684

Post » Wed Jan 28, 2015 3:26 pm

As for the slowness. My game rely on array for its movements (so that many things can happen at same time at same timing and not getting "behind") and it can have lots of movements per "game round" (0.2 sec) and the array is 600 entries big, and it is still a relatively small level for its type of game.

The bottleneck is the searching the whole array for some certain values and it is done often.

If @ashley would like you are welcome to take a look at my game but then it has to be sent privately.
B
58
S
18
G
13
Posts: 447
Reputation: 10,735

Post » Wed Jan 28, 2015 3:31 pm

I'll try and dig up examples/make suitable ones to show our issues, and okay the refresh thing I can understand.

Ashley wrote:I still see no .capx files here. C2 has algorithmic optimisations that CC never had, such as collision cells and render cells, so it should in fact be able to scale to large games much more efficiently than CC could. For example with a huge level doing lots of collision tests, CC would just brute force its way through millions of collision tests, but C2 is much smarter and can cut out 95%+ of the tests by arranging objects in to collision cells. On a large scale, algorithmic efficiency is more important than absolute efficiency. Oh, and in the past we have actually measured Chrome outperforming Construct Classic, which I think now is due to Chrome's parallel & multi-process rendering architecture, whereas Classic was always single-thread single-process.


This is actually why the Javascript + HTML5 + WebGL troubles me, because C2 is fighting harder and yet games made with CC are still faster, I love the optimization that C2 has very much but I think that power could really win with DirectX 9 export (or even OpenGL if you want multi-platform).
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
116
S
40
G
17
Posts: 2,197
Reputation: 19,433

Post » Wed Jan 28, 2015 3:36 pm

Ashley wrote:I still see no .capx files here. C2 has algorithmic optimisations that CC never had, such as collision cells and render cells, so it should in fact be able to scale to large games much more efficiently than CC could. For example with a huge level doing lots of collision tests, CC would just brute force its way through millions of collision tests, but C2 is much smarter and can cut out 95%+ of the tests by arranging objects in to collision cells. On a large scale, algorithmic efficiency is more important than absolute efficiency. Oh, and in the past we have actually measured Chrome outperforming Construct Classic, which I think now is due to Chrome's parallel & multi-process rendering architecture, whereas Classic was always single-thread single-process.


Perhaps it's because most of my projects are less games and more generators of things - so we deal with objects on the screen and almost none off-screen. I'll try to make a "real" example, and perhaps something drastic has happened since I last tried that sort of thing, but C2's output felt slow the moment a couple of thousand bullet behaviour objects came up. Meanwhile CC doesn't break a sweat until tens on thousands.
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Wed Jan 28, 2015 3:40 pm

My two cents on this : )
(pretty important: Please don't jump to conclusions before the last sentences)

Around me, in small or huge game studios, C2 is considered as the best tool for prototypes.
But absolutely not as a real game engine with which you can stick for your full game.
Other devs and me are pushing C2 to Steam releases, major gaming news websites, +150 000 views on some youtube videos, etc...
But this doesn't change anything: when I'm asked what will I do for consoles, I'm answering I'm looking for someone to recode the game from scratch using Unity or Gamemaker. The key word is "from scratch". A port asking for some efforts is normal, having to redo all again, quite depressing.

Publishers are sending emails with big money for Penelope on Sony consoles, and I can't say yes because of html5. With an exporter in any other language, I would be rich now (no kidding). So, I'm stuck, and I know I won't use C2 for my next project (and you can't imagine how it breaks my heart.)

C2 will always be the most brilliant engine I know, I'm in love with it, but due to the "team" size, ressources, and its audience (mainly hobbyists with no need for consoles export), it will stay, indeed, the best tool for prototyping. Nothing less, nothing more.

Now, should I ask again and again to Scirra to do something about it? I'm not that sure anymore. Using C2 to make deep, full games is kind of a hack.
This software is made for people to craft their first games. This is not sold as a pro framework for studios. The tone of the last promotion video is very clear on this.
I sincerely wish the best to Scirra, and I really want them to live long.
The step between GM and GMS has been to hire many, many, so many people. Last time I checked, they were nearly 50 people in there. You can't ask Scirra to do the same if they don't want to. There is nothing in the middle, it's either you're an army and can provide support for all platforms, or you're a few guys and stick to your niche audience.

Making a niche game for a niche audience myself, and not wanting to grow a bigger company, I fully understand the Scirra's choice to not produce and support complex, expensive native exporters. Even if it makes things complicated sometimes.
Image | @AurelRegard on twitter
B
19
S
6
G
1
Posts: 307
Reputation: 2,500

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: RBuster and 13 guests