Ashley's Forum Posts

  • The scripting APIs usually use an array of [r, g, b] for colors, with each component in the range 0-1. What do you need a color value in scripting for? Generally color values are specific to the event system.

  • It's difficult to help from just this information. Can you share the project? Perhaps file an issue following all the guidelines if you think it's a problem with Construct.

    • Post link icon

    Browsers don't currently provide a good way to limit the framerate. You can star this issue to show support for it in Chrome though: https://bugs.chromium.org/p/chromium/issues/detail?id=485600

  • We're a small team with limited resources. I say that a lot because it's true. I'd totally do absolutely all the things everyone ever mentioned if it was possible. Unfortunately we are bounded by the laws of physics. It's not that we're ignoring people, it's just that we get asked to do about 10x as many things as we can actually get done.

    We do lots of things for lots of different reasons. Construct Animate is an effort to grow the business, and if it works out, it could permanently increase our capacity to develop Construct and get more done. 3D Audio was pretty much only done because browsers already implement a 3D audio engine, and Construct was already using it, but not letting you control Z positions so it was locked in to a 2D mode; we just added the ability to set the Z positions, which was straightforward.

    Some things sound easy and turn out to be extremely difficult and time-consuming. Some things sound hard but turn out to be easy. Some things we do directly because of user requests, and others because we think it's the right direction for the company. There's a lot going on, and I can see how it might not always seem consistent. But we're always working hard to improve Construct, and no matter what we work on, we'll never cover absolutely everything that we're being asked to do, because there's just far, far too much we're asked to do for it to be remotely possible for us to do it all.

  • Individual requests may often be presented as simple, but many things that may seem simple are in fact very complicated and time-consuming to develop. Further, if you add up all the 3D feature requests across all the users making them, it amounts to developing a significant chunk of a 3D engine, and that's not a goal for us with Construct right now.

  • Browser makers are emphatic that game-like content should be v-synced (i.e. scheduled with requestAnimationFrame). They are clear that normal JavaScript timers are not suitable for scheduling rendering and preferably shouldn't be used for that. So on this basis alone I think using JavaScript timers counts as hacky.

    It looks like Chrome 107 just shipped 8ms aligned timers, which could have broken existing uses of fixed FPS. It would be interesting to know if Gdevelop/Phaser still work with that implemented.

    Further if you can only rely on JS timers running every 8ms, then you can only achieve a regular 62.5 FPS, which doesn't match common display refresh rates. So I'm not sure how this could be implemented without causing some degree of jank. And then browser makers may well further tighten timer restrictions in future breaking any content trying to use timers for rendering, which they are reserving the right to by saying rendering content shouldn't be done on timers. So it seems like maintenance could be difficult too.

    I don't think a fixed framerate is a magic bullet that will solve everyone's cases, although it might throw in an extra tool to the toolbox if you want to make a tradeoff like accepting janky display for a more predictable physics simulation. But even a fixed FPS isn't guaranteed - if the system can't keep up with the performance, then the FPS will drop anyway. So I still generally think the best approach is to put effort in to figuring out any problems that happen with v-sync and trying to fix it so v-sync works in more cases.

  • Cool results!

    All of JavaScript, browsers and Construct are super fast now, and can achieve extraordinary performance. We're always been keen to highlight this!

  • but as I understood it is not allowed to create plugins that already exist as construct built-in - official

    There are no rules preventing anyone creating addons that replicate built-in features.

    The built-in addons are not however open source and are not allowed to be used by third-party developers, mainly because doing so causes extremely bad compatibility problems. I think you've probably got the wrong impression from that.

  • Nothing in this thread relates to workload. It's about technical complications I mentioned. I could do this very quickly if the necessary browser technology was in place. So I don't see how that has anything to do with this thread whatsoever. I would in fact point to the parts of the Forum & Community guidelines around unnecessarily bringing up controversial topics.

    Further, Construct Animate is an effort to grow the company, get more users, increase sales, hire more developers and advance Construct even further. If it goes well, it could significantly increase our ability to develop Construct. But some people seem to resist the idea anyway, even though they are asking us to do more. I guess you can't please everyone.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Actually try opening this in r318 - I think it might be a bug we already fixed in that release.

  • / is not allowed in folder names as of r317. However this still shouldn't prevent the project from opening.

    In r308.2 I can create a subfolder named open/close in the project bar, save, and open the project in r317; it opens successfully and automatically renames the folder to openclose. So this kind of error shouldn't happen. Can you share your project file or file an issue so I can make sure other similar projects open successfully?

  • Impressive! I didn't know Construct could build things like this too!

  • I'm afraid the safe area values aren't correct at the moment in Android exports due to this Google bug.

  • Unfortunately accurately scheduling frames at half or quarter V-sync rate (e.g. 30 FPS on a 60 Hz display) isn't currently possible in browsers. This Chrome issue could address that - it's pretty old but some more people starring the issue will show support for it.

    Setting a maximum framerate and ignoring V-sync is something that could be done differently for different reasons. However JavaScript timers are pretty restricted these days so even that isn't as straightforward as it sounds - for example Chrome is moving to a model where all JavaScript timers run at 8ms intervals, in order to save battery. So the fastest you can go with timers in that case would be 125 FPS. It's not much more than a 120 Hz display, and is in fact less than some high-end gaming displays. So that doesn't sound like it would help much.

    Besides, do many people complain about input latency for Construct games? I've seen more mentions of smoothness, which would be to do with v-sync, and could be made worse by using timers instead. Construct already uses things like high-frequency raw pointer events in Chrome for low latency mouse/touch input. Either way though, we're pretty limited by what browsers provide at the moment, which is the main limitation (and I would emphasise, that is absolutely nothing to do with Construct Animate).

  • What's the goal here?

    If it's perfect smoothness, like I say, I don't think a fixed framerate will achieve that reliably. I don't see it solving the problem. Perhaps in some specific cases it will look like it solves the problem, but in others, it will probably make things worse.

    So what other reasons are there for a fixed framerate? Perhaps there are some, but I don't see "achieving perfect smoothness" as one of them.

    I also have no idea what this has to do with Construct Animate or why anyone even mentioned that.