Spinning Dorito's Forum Posts

  • >

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

    > Make their own using Node?

    >

    Just thought I would point out something.

    Multimedia Fusion also suffers from this janking as seen in this thread: https://community.clickteam.com/threads ... tus-thread)

    So, I guess this is an example of a native option not being a solution.

    Native is one solution, but like with all things, it's possible to make mistakes so Fusion 2.5 is unable to hit monitor vsync accurately at all times. In this case the engine vendor can fix the problem themselves. I hope Fusion 3 will have fixed this completely.

    In case of Construct 2, the problem is that the ball is on Chrome. The issues are known and at least there's a promise that "there's work being done on it". I'm hoping for the best but not holding my breath.

  • -

  • Edge was particularly good IIRC.

    After keeping an eye out for frame drops, it seems like EDGE is clearly superior to Chrome in hitting VSYNC consistently. In fact I never notice a stutter or a missed VSYNC when testing my game on EDGE. It refuses to miss a beat unless you deliberately stress it, but then it will drop frames consistently too.

    The bug reports on chromium also seem to indicate that when Chrome misses the beat, it's not gonna be 1 frame but possibly more. From what I understood, it could still have a 2 or 3 frame gap between a correct VSYNC and a missed beat after which Chrome gathers itself and composes the image. It would go like frame 1 on sync, frame 2 misses vsync, gets DT of 33, but is composed a total of 2 frames later compared to frame 1, so this makes the jankyness even more pronounced when the correctly DT adjusted frame is displayed with additional delay, then the next frame hits sync and is shown "early" compared to frame 2.

    By association all NW.js projects suffer from this, so it's important to find a way to push improvement to chrome or possibly find a way to hax NW with a temp fix until it's sorted.

    -edit

    these are the issues on chromium. Latest comment does indicate there's work being done, but the more stars these have the better:

    https://bugs.chromium.org/p/chromium/issues/detail?id=422000

    https://bugs.chromium.org/p/chromium/issues/detail?id=460919

  • https://bugs.chromium.org/p/chromium/issues/detail?id=642386

    Get everyone to star this. Also maybe a comment should be added that this affects all games exported with NW.js?

    -- edit

    Game capture works with NW.js v0.13.2 (Chromium 49)

    Task manager showed 2 NW.js processes and I was able to see what the other one was with OBS:

  • -

  • Checked that my project had 5816 files in the animations folder so figured I'd try this too. Adding an animation with 200 frames caused preview to fail in Chrome and NW.js, so I can confirm that it breaks at 6000 files.

    Chrome seems to have a purpose built constraint: https://codereview.chromium.org/18541

    This doesn't affect me right at this moment, but will be hitting that limit pretty soon.

    --edit--

    Since it seems this bug has been closed as "won't fix" before, here's some points of reference:

    This is nethack assets:

    There's 800 unique items without animation.

    It's not at all uncommon for a commercial game to have more than 6000 total animation frames.

    More:

    Single character in street fighter: https://orig00.deviantart.net/ff4a/f/2011/223/a/1/cody_sprite_sheet_from_sfa3_by_anis91-d466t6q.png

    Also the Space Blaster demo provided with Construct has 274 files in the animations folder, that's 4.5% of the maximum.

  • -

  • The bottom left number is the dt when the test drops from 60fps, sorry that was a bit unclear. If that number is not updating, they're running at solid 60fps. Only when it says "JANKY" it's running sub 60fps.

    I've gone ahead and checked issues on Chromium that could possibly relate to jank from vsynctester.com - also starred some of them.

    There's also talk about the --disable-gpu-vsync flag that I haven't been able to get to work.

    On my desktop the CC version can show 3 times as many sprites without dropping frames than on IE, Chrome or Firefox.

  • Props for doing an RPG. I have a soft spot for ISO stuff too, so gonna look forward to how this turns out.

  • Short version:

    "this is a string"

    & lets you combine different types of things, like string, number and expressions like:

    aThing.name

    sample: "You got" & player.PickedCount & "X" & aThing.name

    which can result in: You got 5 X watermelon

    long version:

    https://www.scirra.com/manual/78/expressions

  • Does this help?

    "this is: "&aThing.name

  • That works, thanks. This is gonna add great value to my game.

    One more thing:

    Can this effect be applied to the whole project? (instead of adding it to each of the layouts)

  • Can you try this on edge?

    http://www.vsynctester.com/

    Chrome result: Occasional spike off the charts, some small spikes

    Firefox: Some small spikes

    Running these side by side: Chrome and Firefox do the small spikes in unison (interrupted by OS background processes?), but Chrome's off the charts spikes I cannot explain.

    As for the 16/32/64ms thing, it's from VSYNC. If anyone has a above 60hz monitor, they could try to see if there's more draw windows and thus less janky switch when missing a draw? People have reported that a higher hz monitor increases the fps cap to the monitor refresh rate.

  • Any idea if there's a way to have an on/off toggle for this effect so that in the off state fullscreen scaling would be low quality. The goal is to have the normal state of the game look like it's true 400x224 resolution.

    The only solution I've thought of is to have separate executables for with effect and without

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • On my Windows 10 PC it shows consistently one color. It drops a drame about once every ten seconds. That's about the same as our old native engine in Construct Classic managed. So we have reached parity with native.

    (Why would a native engine drop frames? The OS has dozens of threads to schedule, and sometimes it might just schedule some work somewhere else and miss a 16ms frame deadline. Often if you go fullscreen the OS boosts the process priority and this happens less.)

    That's a crazy logical leap.

    Same as what your native engine did 7 years ago on hardware from that time vs. what your brand new engine on state of the art computers does today does not mean you have parity with native. Here we have newt saying his 8 year old computer can't run a nearly empty project with acceptable performance, on which the same test made with construct classic should work flawlessly.

    I can have DOOM (yes the new one ) idle at rock solid 16ms and max 20ms if you start playing (windowed or not), but a nearly empty construct project will keep consistently missing vsync which causes it to have a sudden 32ms frame here and there.

    Can you have adaptive vsync? Can you draw a frame at 17ms?

    Does Chrome and by association NWJS get low process priority? If so, can this be overcome?

    The jank might not be the fault of Construct, but it relies on technology that cannot in it's current form reach parity with a native engine.

    Please correct me if I have misunderstood something.