Guide: Fix Jank in r190+ Node-Webkit Export

0 favourites
From the Asset Store
You can become a REAL game developer. Learn the basics and get resources that will let you get profits from your game!
  • TiAm Have ever you added "chromium-args": "--disable-gpu-vsync in package.json? You shouldn't have wasted your time.

    I've tried to compare...

    A= node-webkit without --disable-gpu-vsync

    B= node-webkit with --disable-gpu-vsync:

    A= runs smooth in start, then some seconds later, it starts to look Jerkiness in overtime, sometimes it appears smooth motion but not longer.

    B= runs smooth in start, no sign of Jerkiness in overtime, but there is mild jerkiness, looks kinda stable but not perfect.

    I believe B would be workaround to reduce jerkiness.

    Judge yourself.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I completely see Ashley point of view of supporting HTML5/WebGl. It is progressing at an insane pace and really starting to deliver even on mobile.

    What I'd love to see from Scirra is taking this exporters into their own hand/control a bit more. Deliver a working version of node webkit (and don't update if it breaks), and also one for Cordova, since it's going to be the standard for mobile export.

    Is it going to be so overkill?

    Now imagine this scenario happening with autoupdating webviews on mobile

  • When I export via HTML Website, I see .js files. These are JavaScript files, right?

    If Construct2 had the ability to export in JavaScript for desktop, then we'd lose the reliance of Node-Webkit and could export native desktop applications.

    But then again, Construct2 writes it's code in HTML5. But imagine if it could alternate between HTML5 and JavaScript, or maybe something else like C#. That would be make the engine even more powerful and give it some real big desktop chops. But dreams are dreams.

    Construct *does* export javascript... thats why we need something like node-webkit to make an executable out of it because otherwise it requires a browser to run. tho are you confusing javascript with java?

  • C2 exports an html5 page, that is entirely controlled by javascripts files, and as far as I know, unity support something ressembling to javascript to script inside it, but it is a "holemade" version with its own particularities.

    Also it is basically the way the interpreter interprets the javascript that cause that, the problem would still be the same, as there are not a unique JS to native compiler. Even if there was, C2 would still have to support the browsers also, so we cannot plain ignore this issue that happens also in some versins of chrome.

  • If we made our own exporters, it would amount to writing a new browser engine, which companies like Google do pretty well already. Also even if we somehow had the resources to take on Google's thousands of engineers, the result would likely be far poorer quality than what is already available. Consider how many bugs and missing features there are in Canvas+.

    This is an awkward time where a Chrome bug got inherited by node-webkit which is on a slower release cycle. It will inevitably be fixed though. I understand the frustrations, but one bug with a fix on the way isn't an argument to reinvent the wheel!

  • [quote:3t4nps88]Unity uses C#, Boo and a variant of JavaScript and as far as I know it doesn't need exporters like Node-Webkit.

    The scripts that unity uses are not running directly "on the desktop" after export. They merely are an easy way to script your game within the engine. In the end, the regular unity C++ engine core runs on the desktop, and executes what you scripted on top of it.

  • Back on topic, a quick update:

    You can get the old node-webkit (0.10.5) at this address:

    https://github.com/rogerwang/node-webki ... d-versions

    The only drawback is that the "dxwebsetup.exe" file is not included. This isn't actually a part of node-webkit, but it's an installer that's packaged with node exports from C2, and C2 places it in the same folder. If it isn't installed, the export may run in canvas2D mode.

    However, this file is already in the new "NodeWebkitForC2" folder, and it has the same hash values as the file from r184, so I must assume it's identical.

    There is also one extra file in the webkit download from github: "nwsnapshot.exe". This doesn't need to be copied over.

    tl;dr: If you've already installed r190, just download the windows 0.10.5 version of node, and replace the files in 'C:\Program Files\NodeWebkitForC2\win32' with the ones from 0.10.5, making sure to leave "dxwebsetup.exe" in the folder.

    If you're still on r184, it's easier to go about it the way outlined in my original post.

    I'll update the main post when I can.

  • Main post updated. If you're already on r190, just download the correct node-webkit files by themselves, rather than re-installing r184 to get them. See main post for full details.

  • Just tried this and it fixed all my performance issues. Thanks man!

  • TiAm Have ever you added "chromium-args": "--disable-gpu-vsync in package.json? You shouldn't have wasted your time.

    I've tried to compare...

    A= node-webkit without --disable-gpu-vsync

    B= node-webkit with --disable-gpu-vsync:

    A= runs smooth in start, then some seconds later, it starts to look Jerkiness in overtime, sometimes it appears smooth motion but not longer.

    B= runs smooth in start, no sign of Jerkiness in overtime, but there is mild jerkiness, looks kinda stable but not perfect.

    I believe B would be workaround to reduce jerkiness.

    Judge yourself.

    Tried option B in the latest NW, stutters are reduced but still present, very sporadic. It's frankly too distracting to enjoy any game when it happens.

    Reverting back to NW 0.10.5 resolves the issue and its very smooth. The problem is the Greenworks plugin v3 alpha for 0.10.5 doesn't have the Steam Overlay function, only the newer Greenworks v4 (which only works on NW 0.11.x!!) has it.

  • I learned my lesson about jumping to conclusions, it's time you did aswell.

  • On my system, this is still an issue with the latest version of Canary. When V-Sync locks correctly, it's excellent, nearly as good as IE. But it seems to randomly malfunction, causing a terrible stutter every 2-3 frames. Resizing the window usually fixes this, but this glitch has persisted for over a month now.

    Chrome v39 is better than 38, but it's still not as smooth as a well behaved instance of canary, much less IE.

    It's looking like we are a long way from a smooth running version of node, short of using 10.5.

  • How would I go about replacing the osx and linux exporters with the 10.5 version? I replaced the win32 version, and that runs smoothly now. I'm under the impression that osx and linux still run jittery, and I want to fix this as I plan to be releasing a game soon.

  • It's looking like we are a long way from a smooth running version of node, short of using 10.5.

    It's very disappointing, because it infers all those clever people working on chromium... didn't even play test games on it, else they would have noticed the obvious stutter.

    I was showing my C2 build preview on chrome to my nephews the other day, first time they seen it... 5 seconds in, they said "its a bit jerky, whats wrong?"...

  • I just don't get why this isn't farther up the priority list. I thought Google wanted us to move toward rich web, cloud computing, and browser based apps...so why is this fundamental display glitch still around?

    I really don't have anything against the devs, and it may very well be a difficult problem to solve. I'm just baffled that this hasn't commanded a higher priority.

    When simple games drop frames on a powerful laptop/desktop, it's hard not to come away with the impression 'This isn't ready for prime time'. It reflects bad on us -- the developers trying to create content to power the rich web -- and in doing so, damages people's perception of the browser as a new kind of OS, one of Google's primary goals.

    It's frustrating because it feels so damn close with Canary...

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