Construct as a unity editor extension.

  • 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

  • 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:

    [quote:1ga04zqv]

    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.

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

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

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

    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.

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

    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.

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

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

  • I tried to replicate the same project on CC and C2, where the skull spawns X amount of explosions /frame

    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:

  • I think html5/javascript is a good platform to invest in. I do feel at times that the more complex a construct game becomes, the more unstable it runs. There are various small things that have been noticed by users that effect a game's performance, such as function calls requiring more processing, multiple tilesets, etc. And all these things add up, especially if you aren't aware of how to avoid the problems. And who knows what else there is.. There have been many times where I implement something, and get a weird feeling that it should run better than it does- maybe because construct adds extra stuff to ensure a more universal possibility.

    I'm more interested in construct allowing more customization for users, so they can better control how their games can be developed and how they run, etc- there is still so much that can be improved, and construct is already a really great tool.

  • Posted this in the other thread as well, but since it's also relevant here:

    Can confirm jank in 's post on my GTX 1070 + i7 6700K:

    CC: at 950/frame, 28fps (running in background/not in focus), no jank

    C2 / NWJS: at 600/frame, 33fps (running in foreground/in focus), jank

  • Amazing how proof gets ignored hey!

  • The conversation was continuing over here but then got buried:

    I don't think it's being ignored willfully, but I do hope it's on the back-burner of things to look into (as if a performance increase comes out of it, then we all win!)

  • Everyone thinks that making a native engine will magically fix everything. It's not the case.

    But everyone DOES think it.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)