Spinning Dorito's Forum Posts

    Ashley

    I assume you can still have a profiler on the dev version of C2 running while observing the 1 second opening on your end? That can give some hints? Catch the call that takes a lot of time. There might be something small that causes a hickup on newest version of windows, possible even a security vulnerability thing. Looking won't hurt at least. Comparing it to Windows 8 can help too.

    For my project, it's definitely the object count that causes the problem once it triggers. I deleted everything except objects when I had the project running slow. Strangest thing is tho, right at this moment it's working just fine.

    — if you make an extreme test case, I'll test that too to see if it can be reproduced reliably.

    Oh and I have Win10 too, latest updates. Setup is otherwise fast enough to run new games good.

  • It's a chromium bug, there's an open report. This mentions multi monitor trouble: https://bugs.chromium.org/p/chromium/is ... ?id=467617

    If you have two monitors with different hz, vsyncing is going apeshit.

    I think it uses the frequency of the "main monitor" to vsync even if the project is playing on another monitor with different frequency.

    Does changing the icon caching option in preferences affect this?

    ATM the C2 editor is taking 1-1.5 seconds to open a dialog. "Don't show unique icons" setting doesn't seem to have an impact currently. I will try again if the editor becomes extremely unresponsive, like 3-5 seconds territory.

    Haven't been able to pinpoint what exactly triggers the unresponsiveness.

    That's probably coincidental. I get slightly different response time by resetting the computer normally. Sometimes better, sometimes worse.

    I'm wondering if it would be possible to flag some objects to not be shown in the project. It's not a super good solution, but with that I could work normally. My project has plenty of objects that are done and final and never need to be touched again, so those might as well be hidden.

    Can confirm. If I clear my project of anything but the objects, it can still behave slow. 3-5 seconds to open a dialog the first time, then 2-3 seconds the times after that. It's not super consistent. Sometimes it works faster than others, sometimes so slow the project is unusable. At best it's been just 1 second to open a dialog.

    Having another empty project open at the same time and that one will work nice and fast, even if it's open on the same instance of C2 in a tab, so it might not be about some total resources limit?

    Things I've tried so far.

    Capx vs Project folder - no difference

    HDD vs SDD - no difference

    Disabling object icons - no difference

    I'll try to keep my eye on what might make it go into lag-land and report back.

  • It's only really a minor issue. Most games are not affected by it. It causes maybe something like +/- 2px difference.

    It's a meaningful difference for many pixel art games . Also due to it's sneakiness it can go unnoticed when people simply miss jumps without knowing it was an engine inaccuracy that caused it, causing the game to "feel bad"

    Inaccuracies like this have forced me to do an extensive extra rig for the player to ensure jump consistency.

    You can get around it case by case, like for height accuracy you can record your ground Y position on jump, then if your jump peak falls short of your projected max jump height and the jump button is still held down, you move the player to your max height position based on the initial jump Y position.

    There's more to it, but for each game a few special case helpers should at least alleviate the issue, if not remove it completely.

    In the end, jumping games often have a lot of smoke and mirrors going on anyway to improve game feel, like snapping, late jumping, placing the player on a platform they should've missed, conditional control overrides that try to guess the player intent and so on.

    Having the default behavior as accurate as possible will improve game feel for C2/C3 games in general even if they have minimal "helpers" implemented.

  • You could try and increase GPU use on purpose by adding a ton of more additive layers and see if that makes the problem worse.

    If it doesn't then you'll know if the GPU is bottlenecking.

  • I've found problems with the OR block too, but I think the previously picking event wasn't a "pick by comparison" but something else. I might have that block commented out in my events somewhere. Will report back if I find it.

    Initially I thought I didn't understand the picking process correctly, but then figured the OR block was not reliable, so have been avoiding using it in a sub-event.

  • Is there a way to disable preview in editor? It looks quite messy and makes level editing hard.

    -edit

    other than disabling "preview effects" alltogether

  • Introducing moderate load will have Chrome break apart much faster than Edge. Also chromium has multiple open issues on this that confirm it's not working properly. There may be additional issues on older hardware, but everything I have tested show the same results with my jank test where you can increase load to find the breaking point.

  • The hopping skull test shows the differences pretty clearly and is a very minimal project. Also shows jank on the devices that didn't with the sbperftest.

    CC 600 spawns/frame without drops

    C2 on EDGE 150 spawns/frame without drops

    C2 on Chrome or NWJS 50 spawns/frame without drops

    If you want to make a desktop app, the game load is going to have to be at 1/12 of the load compared to the native CC to be jank free.

    If Chrome gets sorted to the same level as EDGE, the C2 NWJS export will be at 1/3 of the performance compared to CC, which starts to be acceptable.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • -

  • As ever, you can make a minimal repro of a problem and file a bug with Google directly. I just checked again and in Chrome, for me, sbperftest's jank meter is locked on 0ms, indicating perfect v-sync. I presume there is something device-specific about any jank issues, and v-sync is implemented in the Chrome browser anyway, so it makes more sense to cut us out of the process and take it up with them.

    I'd like to see some screenshots of people going through a round to see what the max jank is for each user, then also post their monitor refresh rate, OS and specs.

    Would you happen to have a 144hz monitor Ashley ?

    --edit : The refresh rate might not be relevant.

    Tried the test with a laptop and it ran once through with showing 0 on the jank, then updated chrome from 61 to 62 and it started showing random 16ms janks here and there. The change after update might be a coincidence tho.

    --edit:

    Desktop i5 GTX960, 60hz, Win10, Chrome 62 - Random jank throughout the test

    Laptop Zenbook i5 GTX940, 60hz, Win10, Chrome 61 - No jank on the test, Chrome 62 - Random jank.

    Laptop MacBook Air i5 Integraged HD 5000, Chrome 60 - No jank on the test

    Will try to cross reference each of these, but start by trying NW.js with chrome versions 60 and 61.

    Is there a capx for the sbperftest?

  • This is what I've been saying all along - making our own native engines won't necessarily solve any of the problems people think it will.

    To move the issue at hand toward a solution, ideas on how the chrome issue could be resolved are welcome.

    I've starred these:

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

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

    ,but wonder if there's something else that can be done.

    Is hiring a coder to fix this on a custom one off NW.js build for my game a feasible backup plan?

    EDGE runs rock solid dt 1/60 for extended periods and feels so much better than an NW.js export.