Ashley's Forum Posts

  • I would guess your project is indeed using effects, but you've forgotten where they were added. It would be easier to help if you can share your project.

  • The error message is saying WebGL isn't supported. All modern devices should support it and Chromebooks definitely support it out-of-the-box.

    I didn't think browsers provided an option to switch off WebGL. Perhaps there's a 'hardware acceleration' option that was turned off and needs turning back on? Or maybe there is a fault with the device's graphics driver that has caused WebGL to be switched off.

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

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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