Ashley's Forum Posts

  • I don't think that's directly related to the matter of objects sleeping, so I don't think going in this direction will help you.

  • Why does it matter? Sleeping is an internal optimisation in Box2D to avoid processing objects that aren't doing anything. If Box2D does not make an object sleep, it's because it deems it necessary to continue processing it. It's not a bug or something that needs fixing, it's just part of Box2D's design, and applies equally to the many thousands of games across the industry made in a variety of technologies and frameworks that all use Box2D in one way or another.

    It's better to focus on making a good game than running down the rabbit hole of technical minutiae like this.

  • If you need to control instances individually, then you don't really have a choice, you have to add the effect to individual objects and not use a layer effect. If you have an effect on both the object and the layer the object is on, it will process the effect twice, which is wasteful so probably makes it worse.

    It's also not guaranteed that a layer effect will be faster. It depends. There is quite a high CPU performance cost for each effect, so one layer effect has a lower CPU overhead than lots of objects with their own effects. But a layer effect must process all the pixels on the entire layer, which can be a larger area than just the objects on the layer, resulting in more GPU work. So whether or not it's faster depends on the precise balance of number of objects, rendering area, CPU work and GPU work. It's not easy to say conclusively that it helps either way, it's just an option to try - and as usual the only way to know for sure is measure it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Construct is for making games. This doesn't sound like a game. So it's not something Construct has features for.

  • I'll update the target SDK value for the next release. This is routine stuff that happens every year now.

  • I don't think it's to do with the time step. I thought it was because objects have to come to a complete stop to go to sleep, and due to floating point rounding errors this can take a long time. E.g. at some point it will be moving by 0.0000001 pixels, but that does not count as stopped, so it will continue processing it until it drops all the way off floating point precision and finally hits 0. Again, this is something that's entirely happening within Box2D and is not anything to do with Construct.

  • "Scale inner", "Scale outer" and "Letterbox scale" can all use fractional zoom levels to fit the size of the display. Fractional zoom levels mean pixel art doesn't fit exactly to display pixels, and so aliasing (the kind of ripple artefacts you were showing) can occur. The only fullscreen mode that exactly preserves pixel art is "Letterbox integer scale", which was designed specifically for the purpose. You also need the other settings to optimize for pixel art as described in the manual.

    There are probably other techniques and approaches - for example I expect using high quality fullscreen mode and nearest sampling with any fullscreen mode would look OK, because any aliasing will only happen at the level of a display pixel rather than a game pixel, and that may well be small enough to not notice it. But the problem is still happening, it's just much reduced - and it will have other consequences for things like the resolution of text objects. I guess you could also try to hack it like you described, but the "optimize for pixel art" settings are the ones that are known to work in all circumstances, as far as I know.

  • It's meant to look like that. Swipe in from the sides to access bars. See Construct 3 on mobile. You can also switch it back to the desktop view in settings.

    • Post link icon

    It's already on the Steam version - as usual it's simultaneously released there. It's a beta release though, so you have to opt in to betas.

    It sounds like the issue is fixed so closing this thread now. This thread has also already involved two unrelated issues, and long threads like this actually make it much harder to deal with issues, since it ends up with loads of sometimes irrelevant or contradictory information. If there are still any remaining issues, please start a new thread and follow all the guidelines from scratch once again since they are probably also unrelated, and make sure you include all the information we need. Adding to this thread for any further issues will only increase confusion and delay.

  • It's a bug. "\[ [color=#FFFF00] OR [/color] 3" should still apply the color tag.

    In general things like this should be reported to the issue tracker. But I could reproduce this and adjusted the parser so it should be fixed in the next release.

  • FWIW, Construct 3 has a CurrentEventNumber expression.

  • It probably doesn't matter, and worrying about it will only distract you from other more important things that actually matter.

  • Press F12, are any errors logged in the browser console?

  • As of r206, projects exported from Construct 3 using script minification are now processed using Google Closure Compiler. Previously it used babel-minify. For the most part this is a compatible change - simple minification works similarly, and advanced minification does property mangling. However there is one change in how Closure Compiler handles global variables.

    Previously we wrote our own property mangler for babel-minify which supported mangling global variables. However Closure Compiler does not support mangling global variables, unless they are written as properties on the global object. For example console.log(MyGlobal) used to work, but now no longer does. Instead use a global property, e.g. console.log(self.MyGlobal) or console.log(globalThis.MyGlobal). (Note don't use window, because it does not exist in worker mode.)

    Here's another example. Previously you may have code like this: 

    self.MyGlobal = "hello world";
console.log(MyGlobal);

    The reference to MyGlobal will no longer compile with advanced minification. All you need to do is add self. before any MyGlobal references and it will work again: 

    self.MyGlobal = "hello world";
console.log(self.MyGlobal);

    If you use global variables a lot, remember you can refer to them with local variables to help simplify the code, e.g.: 

    function UsesGlobalsRepeatedly()
{
 // Make local variable referring to global variable
 const MyGlobal = self.MyGlobal;

 // Use local variable without needing "self."
 console.log("Use 1: ", MyGlobal);
 console.log("Use 2: ", MyGlobal);
 console.log("Use 3: ", MyGlobal);
 console.log("Use 4: ", MyGlobal);
 console.log("Use 5: ", MyGlobal);
}

    For the record, I think Closure Compiler's approach is better. It avoids any chance of difficult name collision bugs when renaming names like MyGlobal, which if the wrong name is chosen, can collide with local variable names. When using self.MyGlobal, it is unambiguous and safer since it can never collide with local variable names.

    Hopefully this will be a straightforward change for any addons that use this type of code. If you have third-party addons that now fail with advanced minification, this is probably the change you need to make.

  • Losing an hour's work from hardware failure isn't too bad in the grand scheme of things.

    Browser backups are stored internally to the browser, so the only way to recover it is to run the same browser that you made the backup with. If you've moved to another system then I guess you don't have access to that. If there is a way to solve it, I'd guess it'd take longer than an hour, so you may as well just re-do the hour's work that was lost.