Construct as a unity editor extension.

Post » Mon Sep 18, 2017 10:31 am

I am really tired of all these arguments. I already wrote our whole case: the case against native engines

In general the whole argument that "due to <some random issue> you should drop everything and build native engines!" is ridiculous. Why not just fix the issue? Native engines come with their own whole pile of issues, many of which are worse than the issue being raised, so this is just completely off the cards. If we actually did that, I think it could easily be such a big disaster as to risk ruining the company. I guess people are still going to tell us we should do it though.

BTW someone started another thread about v-sync accuracy worrying that it was locked to 16ms and thinking something was wrong - but actually it was v-syncing so accurately the number didn't change. Hardly sounds like a problem ;)
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Post » Mon Sep 18, 2017 10:35 am

Ashley wrote:I am really tired of all these arguments. I already wrote our whole case: the case against native engines

In general the whole argument that "due to <some random issue> you should drop everything and build native engines!" is ridiculous. Why not just fix the issue? Native engines come with their own whole pile of issues, many of which are worse than the issue being raised, so this is just completely off the cards. If we actually did that, I think it could easily be such a big disaster as to risk ruining the company. I guess people are still going to tell us we should do it though.

BTW someone started another thread about v-sync accuracy worrying that it was locked to 16ms and thinking something was wrong - but actually it was v-syncing so accurately the number didn't change. Hardly sounds like a problem ;)


Your article is the case against Construct Classic. My earlier post already explains why this is not a fair comparison:


1. Construct 2 and 3 are way more optimized than CC (or so you say in your blog posts). The only way it would be a fair comparison is if these optimizations were back-ported. If there is negligible gains to be had then all the "such better performance!" blog posts are lies/exaggerations no?

2. Your skills as a coder are better now and you have more experience from CC & C2 runtimes

3. I still notice CC games are smoother than C2, even on my GTX 1070




Also notice at the bottom of my last post that I suggest Scirra get involved in the native wrappers. I accept that HTML5 for the games is not changing. Unity could technically be seen as a native wrapper too, but a better demarcation point would be a project converter.
"Construct 4 lets YOU make advanced games! (they wont run anywhere)" Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
124
S
42
G
17
Posts: 2,228
Reputation: 19,893

Post » Mon Sep 18, 2017 10:46 am

Jayjay wrote:Your article is the case against Construct Classic.

No, it's a case against making native engines for Construct 2 and sticking to HTML5. It addresses your points.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Post » Mon Sep 18, 2017 11:03 am

tunepunk wrote:Trying to follow this thread as it is seems to get a bit out of topic. But what i guess people are saying is...

They love the event sheet way of doing games but not so happy about the c2/c3 as an engine?

I can get where they are coming from, as i would like to try make 3D games, but Scirra has no intention of adding 3d support, and probably would't make an event sheet plugin for other engines. Using event sheet is the only way that makes sense to me. So I'm kind of stuck here, LOL.

All in all I think Construct is a great product though, but I also wish every engine had an event sheet. Kind of like music software has a sequencer/key editor, because I don't really feel like growing a neckbeard and start drinking jolt cola, and learning how to "code" lol.


+1

Hear hear!

I am working in Unity at the moment because our current project is 3D. I would be thrilled to work with event sheets. And, although it is probably a pipe dream at this point, I would love to see Scirra take a stab at combining their awesome event sheet editor with a 3D engine.

The sooner I can get back to working in Construct instead of Unity, the happier I will be. :)
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 » Mon Sep 18, 2017 11:44 am

Ashley wrote:In general the whole argument that "due to <some random issue> you should drop everything and build native engines!" is ridiculous. Why not just fix the issue? Native engines come with their own whole pile of issues, many of which are worse than the issue being raised, so this is just completely off the cards. If we actually did that, I think it could easily be such a big disaster as to risk ruining the company. I guess people are still going to tell us we should do it though.

Jank has been an issue from the beginning, not a random issue. There's probably many issues that are not related to HTML5, but there's legitimate ones also. Don't see people saying "you should drop everything"

I asked before how many work years it would require to have a native exporter as I'm willing to shoulder the financial risk associated. It could be cheaper to have an extra hand working on that than to see multiple indie games being ported to other platforms due to issues that cannot be fixed in time for a game's release. (because the issues rely on vendors beside yourself.)

I'd even consider paying you to make C2 open source.

Ashley wrote:BTW someone started another thread about v-sync accuracy worrying that it was locked to 16ms and thinking something was wrong - but actually it was v-syncing so accurately the number didn't change. Hardly sounds like a problem ;)

You were mistaken, the problem is that there's spikes to 32ms, please try to see where people are coming from. It's clearly stated in the thread.
Also you commented before that dropping frames is normal(it is not if the project is doing hardly anything) (in which case you shouldn't vsync anyway), so you demonstrably know about the issue.

Also please answer the questions clearly marked before.

There are solution-focused ways of dealing with this.
B
27
S
6
Posts: 63
Reputation: 1,511

Post » Mon Sep 18, 2017 11:52 am

Ashley wrote:
Jayjay wrote:Your article is the case against Construct Classic.

No, it's a case against making native engines for Construct 2 and sticking to HTML5. It addresses your points.


I honestly don't see how it answers my points. An (although beautiful) low-collision count top-down racing game and a few tech demos dont hold up to actual CPU-heavy games/platformers on Steam whose developers are telling you HTML5 is not matching up to expectations set by similar tools (eg: Classic and Fusion and GameMaker)

The ones that are already porting to other engines (including us) are finding we can fit more visual FX and complex code into the game yet have smoother performance and support for lower end hardware and even mobile and consoles.

Plus it also doesn't answer: Is C2 really that much more optimized than CC? Because if it is then it stands to reason that CC can't be used as a "native" benchmarking tool.
"Construct 4 lets YOU make advanced games! (they wont run anywhere)" Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
124
S
42
G
17
Posts: 2,228
Reputation: 19,893

Post » Mon Sep 18, 2017 12:18 pm

huZba wrote:I asked before how many work years it would require to have a native exporter

For 100% compatibility with the C2 runtime, essentially never - not before we went out of business pouring all our efforts in to trying to essentially rebuild a significant proportion of a browser engine, which are made by huge corporations with thousands of engineers working round the clock. So, you say, why not throw away the features which are hard? Because lots of people use them, want them, and buy C2 licenses for them, and then it causes a huge compatibility nightmare with porting projects. These consequences are worse than any of the problems you think this might solve.

Jayjay wrote:I honestly don't see how it answers my points. An (although beautiful) low-collision count top-down racing game and a few tech demos dont hold up to actual CPU-heavy games/platformers on Steam whose developers are telling you HTML5 is not matching up to expectations set by similar tools (eg: Classic and Fusion and GameMaker)

There was a bunnymark benchmark recently that showed C2 in Chrome equalled or exceeded those engines. So I am confident in saying JavaScript performance has reached the point where it can equal native.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Post » Mon Sep 18, 2017 12:27 pm

@Ashley Bunnymark was not optimized for each platform. It was a rough comparison at best and there were many people seeing higher results for native anyway.

It is a good comparison of sprite rendering which you have done well with due to WebGL. It would have been nice if WebGL was supported on WiiU for sure.
"Construct 4 lets YOU make advanced games! (they wont run anywhere)" Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
124
S
42
G
17
Posts: 2,228
Reputation: 19,893

Post » Mon Sep 18, 2017 12:37 pm

Jayjay wrote:@Ashley Bunnymark was not optimized for each platform.

I think it was a fair test. I'd be happy for you to provide an alternative test if you want, IIRC someone was hosting the tests openly on GitHub, and the tests were independently created (not something I put together to prove a point). The test is also CPU-bound on draw calls so I think it's a reasonable comparison of each engine's CPU performance. I think it's reasonable to also say that if JS can rival native in this area, then it can in other areas. So if our engine is slow in any respect, it's probably not because of the use of JavaScript. Perhaps we could make improvements in some parts of our engine, but the point is it's probably not slow because of JavaScript. So in this day and age, I think it's naive to say we should change language to improve performance, especially when the costs of doing that are extremely high.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Post » Mon Sep 18, 2017 2:30 pm

I tried to replicate the same project on CC and C2, where the skull spawns X amount of explosions /frame
Image
Both are vsynced. "JANKY" is spawned when dt gets over 25ms.
I'll add touch and such to the C2 one and post on the other thread once complete: dt-is-not-variable-in-chrome-cause-of-jank_t195994
B
27
S
6
Posts: 63
Reputation: 1,511

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 4 guests