TheRealDannyyy's Forum Posts

  • Ah, sorry, I forgot to mention as well that this was in NW.js.

    I investigated further and found this: https://github.com/nwjs/nw.js/issues/6336#issuecomment-352252411 I've been on a version a few versions back, avoiding to update in case it breaks a big project of mine. Testing v0.29.0 it seems the fix has been implemented, however, everything runs at 30 fps now (was hitting 144 fps without issues before) so I'll have to do some more testing, restart my computer and maybe try v0.28.0 too. I'll update with further findings.

    EDIT:

    So v0.28.0 seems to be the best solution for now if you don't wanna fiddle too much. Mouse lock works and the performance is good.

    I found the reason for the poor performance with v0.29.0 (Ashley and NW.js devs are aware as you can see): https://github.com/nwjs/nw.js/issues/6498

    Hopefully an updated version will be available soon that doesn't require manual handling of those command line arguments.

    Thanks and good to know about the issues.

  • Unfortunately I'm unable to use this plugin since at random intervals it seems to read the raw mouse movement as opposite, and at a much greater speed compared to what I'm actually doing. So say I'm moving a sprite using the raw values to the right and it's reading raw X at around 2 to 9 - suddenly it will jump to the left at a raw x value of something like -280 for no apparent reason. Anyone else experiencing this?

    See these logged raw values as an example: <image>

    I believe this is the fault of the API and not of the actual plugin code. The Mouselock API is known for being buggy like that sometimes.

    Do you have the same problem when using "normal" and not "raw" coordinates?

    (P.s. We're currently having a completely reworked plugin in testing which will add C3 support and might fix issues like that as well.)

  • I've had a very similar problem to this with intense slowdown occurring every 30 minutes or so.

    I had found a temporary fix in which I had to close any dialogues and then minimize and then un-minimize C2. ...

    Same thing for me but I'm not running C2 on a laptop so it must be something else causing these slowdowns.

  • I'm sorry, I don't mean to troll you, I'm just describing exactly what happened last time we added a performance workaround. We add a workaround, then someone immediately asks to fix it without the workaround. ¯\_(?)_/¯

    No problem. Although I can understand that people would request a quick fix because they might not have the time to wait for the whole process of isolating the bug and fixing it. Sadly this doesn't seem to be an easy one to fix.

    So, just to be clear, you don't have performance measurements to back this up?

    I've never seen or heard any such cases of high-DPI causing performance issues in C2 games, unless it's due to GPU bandwidth limits. The option to disable high-dpi mode in the runtime is essentially a variant of "low quality" fullscreen mode. I don't think there's any kind of parallel to the editor there, editing software does not usually come close to GPU fillrate limits, it's entirely different to game rendering.

    You're right, I'm just assuming that it might be at fault and the problem is that I wasn't and am not able to test this out. I don't own a Win10 system (yet) and I don't want to cause any damage to the systems of the people that helped me out with testing so far, by manipulating the registry or whatever is necessary in order to force disable it for reproduction.

    The high-dpi setting in exported games only seem to affect some systems, not all of them. All I know is that disabling it helped those systems to run the game well. It's always difficult to narrow down the main cause for performance issues but I guess the slight quality improvements when using high-dpi were too much to handle for those systems.

    On a different note, I've recently received a PM by a community member and Windows update "kb4087256" seems to have fixed all of his slowdown problems. He's provided a screenshot with the updates that probably fixed it and after looking up the changes of each individual update on Microsoft's support thread, "kb4087256" seems to be the one which might be the solution to all of this. It would be great if you and generally everyone without slowdown issues could temporally remove those marked updates and test if any slowdowns occurs. If the updates are missing, I'd appreciate installing them and providing feedback if it fixed the slowdown issues.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you mean "Override high DPI scaling" setting on Compatibility tab in C2 shortcut - I tried this and it didn't help.

    In fact, I tried all compatibility settings and none of them made any difference.

    If that's the case then high-dpi is probably not at fault for the slowdowns. I'd still like to get more feedback from more users before dropping this though.

    Thanks for testing it out and providing feedback!

    I'm a bit confused, are we not already able to turn off high-dpi scaling in the settings on our C2 projects ?

    Yes but this is for Construct 2 itself and as far as I'm aware it makes use of this feature.

    ---

    This seems to raise more questions than it answers...

    Which setting, exactly?

    I didn't know that - which setting has changed and how? ...

    Windows 7 + Win10 (before update) / Win10 (after forced dpi update)

    I assume that C2 has high-dpi support enabled by default, which could be the reason for why users started experiencing performance issues more recently and not before that mentioned update that started forcing high-dpi mode.

    C2 has had basic support for high-DPI for as far back as I can remember. There's nothing we've changed on that front for a long time, and C2 should not have been using a compatibility mode, because it is natively system-DPI aware.

    The latest changes were done in r229, assuming that high-dpi is indeed the cause for slowdowns it would make sense for people which experience these issues without having a Win10 system with the latest updates.

    This would make the whole UI look blurry. I'm sure the next question would be "how do I make sure the UI looks sharp?"

    Could you please stop being "trolly" and stop putting words in my mouth. I'm trying to have an honest and polite conversation which hopefully ends up in finding a solution to this problem. (I know you've had your fair share of bad experiences but I'm just trying to help by providing possible causes for this impactful issue.)

    We already worked around the event dialog performance issue by implementing a special setting, and then the next question was "how do I fix the performance issue without using the special setting?", so it seems these kinds of workarounds are not satisfying to users.

    This isn't really a request for a long-term settings option to degrade the quality of Construct 2, it would a temporally (beta) option in order to maybe find the cause for slowdowns and help you out to narrow it down and fix it. Unless of course you've found the cause already, in that case I'd really appreciate a heads up about it!

    What evidence is there that this does cause the performance issue? What measurements have been made with which combinations of settings and how do they compare? I don't see any evidence at all for this right now.

    That's the issue, as far as I know Win10 doesn't allow to disable high-dpi in the properties anymore (at least the community members I've asked couldn't find a way to disable it completly). Based on a more recent report about high-dpi and performance problems and the before mentioned updates in r229, which exactly fit the the affected parts of Construct 2, I thought this might be the fault of high-dpi. High-dpi is known for causing bad performance even in exported C2 games which lead to my assumption based conclusion that it might be at fault.

  • Ashley After doing some research with members from the community which experience performance issues with Construct 2 on Windows 10, I've come to the conclusion that "high-dpi scaling" might be at fault.

    Just a quick note before we go into more detail, Microsoft decided to drop the legacy option to disable application specific high-dpi scaling and pretty much force enable it now, so I couldn't fully test if it's indeed at fault for all performance related complaints that have been reported over the recent months.

    TL;DR: I would appreciate if everyone who'd like to participate in this topic, could refrain from posting raging assumption based conclusions.

    As you might already know, Windows 10 more recently decided to only allow users to override the dpi setting and not disable it completely. However I found out that it's possible to set it to "Application Mode", which basically means that C2 has full control over the dpi mode. I assume that C2 has high-dpi support enabled by default, which could be the reason for why users started experiencing performance issues more recently and not before that mentioned update that started forcing high-dpi mode.

    What does this all mean and why should you care about any of this?

    Simple, with an added option to disable high-dpi as a whole for C2 (despite it's downsides of overall quality), users that experience performance issues could test it out and provide feedback which could lead to the conclusion that high-dpi scaling is indeed at fault for the most recent performance issues with C2 on Win10.

  • TheRealDannyyy - I don't think you understand, that in engineering terms, undocumented features exist for a reason. As I mentioned in that other thread often it allows us to move quickly and make radical changes without the burden of backwards-compatibility dragging things down. So some features will remain undocumented for that reason. Again, all products have undocumented features, and experienced engineers know not to rely on them or at least not to expect any support for them - this is not controversial or new. We're actually in general more closely aligning ourselves with the industry standard approach. Outside of that though, we will make sure we document as much as possible.

    I do understand but I don't know why you would hide cutting-edge features, despite the things you've mentioned.

    My point is to expose those features and let JS-Dev's deal with depreciation or similar breaking changes. They should be responsible for using cutting-edge features and all future changes which might break their addons. It's kind of like Scirra using cutting-edge web technology in Construct 3, something changes, you have to adapt to it.

  • Just to add something to the discussion since I've kinda started it with my question in Tom's topic.

    I'm personally fine with everything you said Ashley and I'd accept good support in exchange for an "open source" system.

    However if you're going to provide support (direct or indirect through the docs), make sure that you share everything that could be considered as useful by JS-Dev's. If you keep certain features secret because of whatever reasons you come up with while actively using those features yourself, this will in my opinion go nowhere and only frustrate JS-Dev's to the point where they will probably drop any future work for Construct 3. Customers that bought Construct 3 then might regret their purchase because they could've bought Construct 2 with support for thousands of addons instead.

    Take this an example for my reasoning:

  • I'd prefer to see how the bug reports go first. We have to support a range of platforms, not just NW.js, so I'm most interested in the broadest fix possible. Even if we added this to NW.js, if there really is an issue with the GC performance, it'd only be a matter of time before it came up again with Chrome or Cordova apps on Android, so this seems to be the best approach to start with. Also if it doesn't happen in other browsers, that is good evidence it's fixable.

    I'm alright with this approach, I've reported the issue. (Link)

    Hope that everything is alright with my report and that they'll respond soon.

    Thanks for your time and I guess the rest will be done over there!

  • Only the "full" version points at GC (labelled "DOM GC (complete sweep)" - not sure why it's doing that...). The "cut" version just shows a long tick but unfortunately doesn't seem to indicate why that is.

    You can definitely file this as an issue with Chrome. Nobody needs to have any knowledge of the internals to file a bug, just make a web repro, attach the trace you recorded, and say the issue is it spends too long in "DOM GC (complete sweep)". I've seen them fix similar issues in the past too, no need to assume that it's impossible.

    Great can't wait to report this over and over again...

    What about my request towards manual GC, would you be interested in implementing it?

  • I don't think this quite qualifies as proof the jank is caused by GC. Could you try taking a performance profile over the time that causes jank? Press F12 to open dev tools in NW.js, and then start a recording in the Performance tab and try to capture the jank. If the performance profile measures the jank and actually tags the time period spent as some kind of GC, that would prove it. Until then, best not to jump to conclusions! I tried this myself but couldn't see any issue (over 30 seconds it spent <10ms in GC), but I do have a lot of memory on this system. I also tried pressing the "collect garbage" button in dev tools while the performance profile was recording, and again no significant GC time was measured.

    I could reproduce "jank" on two different tests, here are the results:

    Full version (recording after memory loaded): Download

    Cut version (recording after layout switch): Download

    Even if it is GC, I think it would be better to file a Chrome bug to optimise this aspect of the GC. It looks like it only needs to unload 5 tracks, and freeing memory should essentially be a matter of tagging some memory regions as free instead of in use, i.e. very little work. So I'm not sure what it could be doing that would take any noticable amount of time. If there is a problem and it gets fixed, then it also improves all games everywhere else the Chromium engine is used, e.g. in the Chrome browser, all Cordova games on Android, etc. So this would improve all platforms, which is a much better end result, rather than providing a hack to work around a GC performance issue in just one variant of the Chromium engine.

    This is where we have to find a compromise. I don't believe that any fix provided by the Chromium Team (given they do something about it at all) will fix this. Even if GC would do this in smaller chunks to avoid expensive full heap collections, it would probably just result in multiple smaller "janks" and make it worse.

    I also have no clue how I would report this to them with next to no knowledge about their whole GC system. I could only provide them vague assumption based conclusions like I did here, which they would probably ignore and won't bother looking into.

  • Do you have any actual problems that would be solved by this, or evidence that jank is actually caused by GC? I've never been a huge fan of garbage collectors but browser's modern GCs are pretty good and do generally slice work in to small (non-janking) updates and concurrent collection. I haven't seen GC obviously causing jank for some time now. Most jank issues seem to come down to some kind of system v-sync timing issue, and the last other cause I saw in the forum, was forcing synchronous texture loading during gameplay.

    That's indeed the case for the most jank reported on the forum, Vsynctester in my opinion the best proof for v-sync timing issues and jank but that's another topic for another day and I'm aware of synchronous texture loading during gameplay jank, that's why I proposed a new memory management system on the C3 ideas website.

    I've slightly modified an example that demonstrates force unloading. Please note that this is incredibly difficult to reproduce on systems with 8gb+ memory, however not impossible since I managed to reproduce it a couple of times myself.

    Download example & Steps to reproduce:

    • Launch example in NW.js (tested in v0.28.0)
    • Load stuff into memory by clicking "load all audio files into memory" button (about 1gb total)
    • Tell GC to unload stuff by clicking the button
    • Switch to the "game" layout by clicking the button on the top-right corner
    • Observe GC unloading memory "mid-game" causing major jank (this process happens at random, sometimes immediately, sometimes delayed)

    Repeating myself here but despite GC being considerably great for the most part, the main issue persists: control.

    I'm sure you know this already since you've worked on native software yourself but an important thing to software and game Dev's alike is to have control over memory usage. While having an unpredictable automated GC system like this in place can be an amazing thing, it doesn't always work out with every project and having an optional method to manually manage memory would be tremendously useful for those projects, regardless of them being a small minority in comparison to others that don't need it.

    The GC is designed to as far as possible only use the lower levels of GC and avoid expensive full heap collections, and even then if it has to, it tries to do it concurrently...

    My example proves this to be wrong. If executed correctly, you will be able to see that GC pretty much unloads everything at once, same as when it's being forced.

    Also I'm not sure but it might even force it to be synchronous (no time slicing/concurrent work). Browser GCs are also generally pretty good at scheduling these only when it's needed, so if you force one ahead of time, chances are it's not needed and there's not much point doing the work. So, in fact, adding this could make jank problems worse, not better.

    I've been told that this feature is exactly like pressing the "bin" icon in Dev-tools. Would you mind providing some sort of proof that it's indeed causing those problems? I'm using it in my project for a while now and I've never experienced any issues with jank getting worse or GC not working correctly after manually forcing it, even if it would cause GC to stop doing things automatically, I would consider that be a good thing and not necessarily a bad thing.

  • This request is mainly about some changes that could further improve the general user experience with NWjs.

    The majority of advanced users require desktop games to do things on demand and not based on "automated" systems. I would like to request an update to the NW.js plugin and package.json files (manifest), which would make it possible to force the built-in Garbage Collector to unload unused audio or similar objects instantly on user demand.

    I'm sure that the automated garbage collector is considered to be "perfect" by the most web developers but coming from a native-tech background, my opinion still and will always stand: it's flawed and will always be flawed regardless of how many updates and tweaks it gets.

    Putting any personal bias aside, this request doesn't take GC away and would just add an option to trigger it on demand. This could be tremendously useful for larger games with for example: selfmade loading screens and would prevent any GC related "jank", that may occur on an active layout caused by automatic garbage collection.

    Requirements for

    Construct 2 implementation:

    • Forced replacement update of manifest files*
    • Always exposed GC by adding simple js-flag (Screenshot)
    • NW.js Plugin new action "Push Garbage Collector" which executes js: "global.gc();"[/code:3qcombfs]

    *I would suggest publishing a beta update announcing the upcoming changes so that users with customized manifest files can do a backup.

    Requirements for

    Construct 3 implementation:

    • Always exposed GC by adding simple js-flag (Screenshot)
    • NW.js Plugin new action "Push Garbage Collector" which executes js: "global.gc();"[/code:3qcombfs]

  • You do not have permission to view this post

  • Is there a plugin for C3 as well?

    Asked Armaldio about this and he says that should be doable.

    It might take a couple of days so I'd recommend subscribing to this topic to get notifications about the latest progress.