Ashley's Forum Posts

  • Worker mode runs exactly the same code, but in a different thread. So it probably won't be running the same code any faster, but it has better performance characteristics, as anything that blocks the main thread can jank the game in DOM mode, but can continue running smoothly in worker mode. In a standalone app like NW.js there should not be much that affects the main thread, it's more useful for stuff running in browsers where there is more likely to be main thread contention.

    As ever, if you want to know the real answer about a performance question, measure it yourself. If you can't see that it makes a difference, it probably doesn't matter.

  • The WebView2 export option supports fullscreen mode if you use the Browser object's 'Request fullscreen' action.

  • It appears to be this NW.js bug. I believe you can work around it by turning off worker mode in Project Properties.

  • Picking is a concept unique to Construct event sheets, and is not a concept that exists in other programming languages like JavaScript. However you can write code that achieves the same result, and script blocks in event sheets can access the instances picked by the event's conditions. There's some more advice at the very end of the 'Learn JavaScript in Construct' tutorial series.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The whole point of an orthographic view is the distance from the camera doesn't affect the size. You could try scaling the layer/layout instead.

  • The 3D Camera object provides expressions that can convert from layer to canvas (and back) with a Z co-ordinate.

  • To be clear, the problem is not resolved, and in its current state it will not be resolved. The problem is blocked on waiting for someone with an affected device to share information about the system. It is not possible for us or for Google to identify this information, as nobody can reproduce the problem, and only customers with certain system setups are affected, but the type of affected system is currently unknown.

  • No idea - it should work. Perhaps you have some browser extensions that are turning off features? Sometimes extensions turn off things like file system access "for privacy".

  • It should work in a supported browser. If you exported and tried in a browser like Firefox or Safari, it's not supported there yet.

  • We have not made any intentional changes to how this works for several months now. I suspect it was not really a Construct update that changed. However if you really want to look, you can always check past releases yourself.

  • I've added #1 and #4 for the next release cycle, and fixed #2 (which is a bug and could have been reported as such - the public SDK should always work in terms of public types and not internal types). I think #3 would be a fair bit more work though.

  • It looks like it ultimately is calling this method, in which case "an integer handle" is really just an actual "int", i.e. a normal 32-bit number. So you can just pass that around the event system as a standard number parameter.

  • Oh yeah, there's a forum bug there... replace & in the URL with just & and it works.

  • I dug out an old C2 performance benchmarks used for collision cells, and adapted it to show all the content on a single screen: https://www.dropbox.com/scl/fi/8r2r91i0q84ay5454rssh/Overlap-benchmark.c3p?rlkey=x562ztroagbmoonxr057j4tes&dl=0

    It uses 1000 objects all testing overlap with each other, which causes ~1 million collision checks per tick. On my high-end desktop system that results in ~40 FPS with CPU maxed out. I think it's true that some games will use this style of heavy content on a single screen (Vampire Survivors being a good example, as well as bullet-hell style games), so it's a good test case and collision cells don't work well by default in that case as the collision cell size is the viewport size and so collision cells don't help.

    I added a way to change the collision cell size and it does help a great deal - for this benchmark the sweet spot seems to be about 50x50, which is a lot smaller than the default. That results in a smooth 60 FPS and ~25% CPU usage, so it's several times faster. I think that also shows collision cells can be a perfectly good solution if the size can be tweaked for the game - I'm not sure there's any reason to go further with more advanced algorithms. Too small a cell size does end up slower as the overhead of tracking cells outweighs the performance saving, but it seems fairly easy to land in the right ballpark and get big improvements.

    It remains to be seen if any complications come up but I've added action to set the collision cell size for the next release cycle, so then it can be experimented with and tuned for specific games.

  • FWIW some people are still reporting this issue, but at the moment it's infeasible for us to fix it as it appears to depend on specific and currently unknown hardware/driver combinations.

    Since as far as I'm aware nobody has yet reported the issue to Google as I advised, I created a report myself with what little we already know about the problem here: https://bugs.chromium.org/p/chromium/issues/detail?id=1501367

    Predictably the response was asking for details about affected devices.

    If anyone can provide the information Google are asking for in that issue report, it may be possible for this to be fixed relatively quickly. If nobody does this though, this will only be fixed in several years after all the affected devices fall out of use.