Ashley's Forum Posts

  • 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.

  • Usually the biggest source of problems is buggy graphics drivers, which is not actually Construct's fault, and those will cause problems no matter which technology you use. Welcome to computer graphics - poor quality drivers have been a serious problem for decades and even sometimes ruin major game releases. The best approach is to install any available system software updates or driver updates on affected devices, but that does not always help, as sometimes the latest drivers are still broken.

    If you can track down specific affected devices and report the issue to Google at crbug.com, you may be able to get a few specific cases fixed in Chrome, but it's hard work and you'll need detailed information about affected devices and access to them to test subsequent changes made.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The basic feature of multiplayer is sending messages. You can implement whatever custom filtering or synchronization you like on top of sending custom messages to specific peers. The built-in stuff basically is just a predefined synchronization system based on sending certain kinds of messages to certain peers, and you can make a different system by sending your own types of messages.

  • I think you can work around this on the latest versions of NW.js by turning off worker mode in advanced project properties.

  • LOS only casts a single ray to the given position. If you test LOS to an object it only checks the object origin position.

    Testing if the whole shape or any part of the shape has LOS is tricky - you have to cast multiple rays across the object to check if any part of it is visible; for a 100% accurate version you'd need to cast an extremely high number of rays which would kill performance; and for high performance you need to cast as few rays as possible, which means certain size gaps or overhangs will not be counted as visible even though they would be with a 100% accurate system. So there is a performance/accuracy tradeoff there. The LOS behavior gives you the single ray primitive so you can build your own logic that makes your own tradeoff about how to detect larger objects. One simple scheme is to add a few image points around the edges of the object and check if there is LOS to any of those. There will still be edge cases where the object is not counted as visible when it is though.