Jayjay's Forum Posts

  • Amazing to see this game running on portable PC's: https://twitter.com/acampy/status/910681476110438407

    Looking forward to when it's running on Switch and PS Vita too in 2018! <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

    Also, we just released a new Teaser Trailer today too!

    Subscribe to Construct videos now

  • why do we get janks even if our games are frame rate independent ???

    is it because the code can only ever use the previous dt in the current loop? so a single spike dt throws everything off. i.e. you need a more constant framerate for framerate independence to work smoothly ?

    I think it mostly comes down to JavaScript being awful ( https://medium.com/javascript-non-grata/javascript-is-a-dysfunctional-programming-language-a1f4866e186f ), especially when it's not created via compiling C++ into JS with something like asm.js, but mostly also because it has poor memory management/"garbage collection" that will build up unused memory (eg: destroyed objects and variables) until it purges it and usually cause some lag. Many developers have been trying to improve this, as it's an issue larger than just Scirra: http://tinyurl.com/y8wfs8kx

    If I remember correctly, I think Scirra/Ashley actually has some great methods of reusing data to help combat the garbage collection.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Would a call for another wrapper fair any better than a native export?

    Make their own using Node?

    >

    > > You're only comparing the Chromium engine - have you tried Edge and Firefox? They have different v-sync engines. Edge was particularly good IIRC.

    > >

    > Chromium is the only option we have if we export to pc.

    >

    Would a call for another wrapper fair any better than a native export?

    Make their own using Node?

    Good idea, a dedicated wrapper would probably make a difference even if they never go into making a fully native engine. It might even mean they can make ports of Node exporting to consoles themselves.

    I think if they are willing to dig down deep enough into it, there are some performance gains to be had for sure.

    eg: Having something designed specifically for use by Construct might even mean they can do some native speed-hacks perhaps? (eg: intercept JavaScript math functions and return the result in some C++ code instead maybe? also for the built-in C2 plugins maybe they can offload that into some C++ code too?) even more useful would be if they had better control over the garbage collection/memory management, but I don't know if Node would enable that.

    Events for general game logic should be fast enough even if they are in JavaScript, but things that happen every single frame are going to be a source of jank, especially with the memory management/garbage collection being so bad in HTML5.

    Also, here's my results for testing in Firefox and Edge with — 's project and C2 r246 running fullscreen on 1080p monitor with GTX 1070 and i7 6700k:

    Firefox: "JANKY" starts at 300/frame, gets awful at 400/frame, with dt reporting anywhere from 25 to 35

    Edge: "JANKY" both starts and gets bad at 600/frame, dt hitting 25 to 30. Gets as awful as Firefox at 700/frame

    I tried exporting CC to fullscreen and was able to reach 1300/frame before it started saying "JANKY" a lot, and even then it was still pretty smooth/didn't cover the whole screen in Janky

  • Holy crud, where have i been?? when was this released? IS it complete and bug free or an alpha?

    It was "released" a couple months ago now, but it's still technically in beta I think.

    Only an editor change so far, the export still runs on the Construct 2 runtimes/exportrs, but now the editor does work in the browser itself which is very neat on a technical level (only other HTML5 tool I've ever seen do that is SuperPowers).

  • 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

  • I made a test for others to see if they get the same results as I do.

    The skull spawns explosions each frame, you control the amount with +50 or -50.

    When dt goes over 25ms, it spawns "JANKY"

    CC exe: https://www.dropbox.com/s/4ckkxbez7iou0 ... C.zip?dl=0

    CC project: https://www.dropbox.com/s/ysfbukb3jnrpw ... l.cap?dl=0

    C2 NW.JS export: https://www.dropbox.com/s/uv9tw0guvq0vs ... w.zip?dl=0

    C2 project: https://www.dropbox.com/s/fos16fpcahcm4 ... .capx?dl=0

    Results for me:

    CC: at 600 /frame, no jank. Can stay jank free for minutes.

    C2: at 200 /frame, jank every second on Chrome and NW export.

    C2: at 50 /frame, Random jank every 5 seconds or so on Chrome and NW export.

    Can confirm on my GTX 1070 + i7 6700K:

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

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

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

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

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

  • Cryptwalker Xbox One likely has better performance thanks to Edge and WebGL, but what Scirra called console export on the Wii U was not good enough to actually release an action game on.

    That said, console export was the largest draw of funding for our latest successful Kickstarter and if we werent using Unity there would be a lot less interest as most of it was PS4, Switch, and Vita. Saying games do best on PC is simply not looking accurate to me comparing C2's best sellers to games like Super Meat Boy and Shovel Knight.

    There are some kinds of games that will sell great on PC, but there is also more competition due to lower requirements to enter the market, and even if you have many Steam users showing up on SteamSpy a lot of those could be people who purchase resold keys from bundles and giveaways that make you effectively no profit.

    Overall though, console support matters, especially to indies working commercially.

    Unless Scirra start getting hands-on with making at least native wrappers for consoles, mobile, and desktop themselves (I'm happy enough with ports of open source wrappers even) and take accountability for them, I can't recommend serious projects to be made in this until the day every single device, mobile/console/desktop, is running a real Chrome browser equivalent and has specs matching a PS4 or higher.

  • We did make a native engine in Construct Classic, and it still occasionally dropped frames.

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

    I love when Construct Classic is being brought into this as if it compares to Unity or GameMaker.

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

  • https://www.dropbox.com/s/tyfj5687kmvf8 ... .capx?dl=0

    Windows 10

    Chrome Version 61.0.3163.79 (Official Build) (64-bit)

    HW: desktop i5-6400, Geforce GTX960

    It randomly shows frames of 2/60 if minimum framerate is 30 and sometimes 3/60 if you lower the min fps to 10.

    Why does it drop to 30fps from a slightest irregularity? I'd rather show the next frame after 17ms instead of 32ms.

    This shows noticeable jank while scrolling fast and when there's a sprite trying to flicker at 60hz.

    Running Windows 10

    Construct 3 preview window fullscreen

    Chrome version 61.0.3163.79 (Official Build) (64-bit)

    HW: desktop i7-6700k, Geforce GTX 1070, 1920x1080p dual monitors

    Can confirm that the sprite flickered once or twice, even while standing still, sometimes it's staying white, other times it stays black, but generally it was 1/60th of a second.

    However, I'd like to see a NodeJS export, as it was noticeably smoother in Chrome than any of my experiences of Jank in NJS/Node-Webkit

  • Now whether the amount of work involved would be worth it, that's another matter.

    Also sort of a reply to Ashley: It is if you want console and desktop export, and technically also mobile export since why would you use HTML5 on mobile when you can just export real Android and iOS apps??

    As for "A closed source game engine which doesn't care about us at all", I think there's three major issues with that way of thinking:

    1. Chrome/FireFox/whatever is for all intents and purposes a web browser, the ability to render interactive content is something they're improving (SLOWLY) due to HTML5 + WebGL being included in the web standards, but game engines inside HTML5 are not their main focus, and for anyone following the Chrome jank issue they can see that it's been going on for years. We have been lucky with some fixes so far, but I don't think we can assume that anyone on their end really specifically cares about making C2/C3/our exported games work in their browsers. Ashley has been doing a great job at pushing for fixes and I appreciate that, I love Construct and I wouldn't argue if I didn't care about its future.

    2. If Unity was a tiny obscure company I'd mind the closed-source part, but when is Scirra going to get their hands dirty in the source code of these open source browsers and make their own player app that's optimized just for Construct games? That's what I'd need to see to believe that a company which hires hundreds of employees to make a game engine is going to be beaten by a small middleware company with a much smaller customer base.

    3. Also still considering Unity being a dedicated GAME ENGINE, and that's how they make money, I think it's silly to say they don't care about people being able to make games in their engine. In fact, they've shown more willingness to adapt and change for what their users want than I've seen in a lot of the "more personal and friendly" game engine companies that often attract indie devs by advertising there's no code required (when everything is really just logic, and if an indie had the time to learn they could probably script in LUA or JavaScript without much issue).

    Sure, they might make drastic changes that require re-making the plugin, but since C3 so far is just a re-skin of the C2 runtime what's the problem with making new editor interfaces every few years and re-selling? Might as well make it a yearly subscription eh! (and I'd actually pay for it, for real, because Unity is not designed for 2D and it still feels like an add-on, plus events are just nice and I'd feel much more comfortable using them if they exported to some C#/.NET bytecode underneath )

  • Well, a standalone Construct 3 is in the works ( I hope still the case ) , so ultimately not reliant on anything.

    That's the editor, not the runtime.

    That said, I guess it'd be kinda neat if the free version of Construct 3 was the "Player" for apps too, so then it's an all-in-one EXE/etc that you can distribute to people. eg: if it detects a game project already in the folder, the EXE switches function to a game only, unless the developer has specifically chosen to allow someone to edit their game (then at start it asks if you want to PLAY or EDIT game).

    newt Well sure they pretty much have their own Arcade so a desktop version of that would be nice and a Steam plugin? Yes please!

    But seriously a wrapper to native is actually much more useful than just on Steam. It's something Scirra should have had better control over for a long time now/before starting work on C3.

  • Hard to build a business that's so reliant on another business and who can pull the rug out from you at any time.

    Great point, so when is NodeJS/Node-Webkit getting replaced with a Scirra-made exporter?