Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Like I said, if the goal is perfect smoothness, then running the engine at a different tick rate to the display rate probably won't look perfectly smooth.

  • Browsers don't currently provide a way to drop the framerate. There's this Chrome issue about that, but it's quite old now.

  • It's not really clear from this thread if the problems are caused by v-sync or would be solved by a max FPS.

    Turning off v-sync brings its own problems too. For example if the display updates at 60 Hz, if the game ends up running at 85 FPS it might look jankier than running at 60 FPS. In that case ticks won't line up with displayed frames and so there is an inconsistent amount of movement every frame. So if the goal is perfect smoothness, this doesn't seem like the way to go.

    The best solution is to make sure v-sync works solidly. It seems to work perfectly smoothly for me if I open the "flying along" template. I'm not sure why it wouldn't on other systems. I think the best thing to do is file issues with browser makers if any particular browser is not v-syncing perfectly smoothly.

  • It's not clear that topic is related to this - it doesn't mention the same erroneous reading, and there are other reasons you may have a smaller quota than available disk space (e.g. private browsing modes often set a small quota).

  • Things only mentioned on the forum are at risk of being lost or forgotten, given the volume of daily posts. We look at the issue tracker to see our list of issue reports in one place. Would you mind filing it there to make sure we see it?

  • Can you please file an issue for this? We generally need all the requested details to be able to help.

  • After running this service for about a month, we're happy to now move this out of experimental status to an officially supported service. The original post has been edited to reflect this and the fact we host a TURN server has now been added to the Multiplayer documentation. However please note the disclaimer, which points out this service is provided for free on a "best effort" basis, and we do not guarantee any particular quality of service. If this is unsuitable for your needs, you can also host your own TURN server, which is also covered in the documentation. While we reserve the right to end this service at any time, we will endeavour to provide 30 day's notice if we decide to shut it down permanently, in order to allow time for alternate arrangements to be made.

  • That's weird, the usage amount looks like it's returned some maximum value rather than the real value. That number comes from whatever the browser tells Construct is being used. So I guess it's a bug in the browser. You can probably just ignore it.

  • IIRC, on Xcode versions older than 12, the emulator doesn't support WebAssembly and so Construct 3 games don't run. That issue never affected real devices, only the emulator. This was fixed a few years ago and it hasn't been a problem since. I don't know why anyone would still need support for old Xcode versions.

    Without more details, I'd guess that a crash on an Android emulator is due to buggy graphics drivers that can cause crashes, which is a problem we've seen before. That's a problem with the emulator, not Construct, so it's out of our control. Again that usually does not affect real devices.

  • It generally means there's a system-level problem such as broken graphics driver. As the message suggests, the best thing to try is installing any available software updates for your system.

  • Oh, I missed that this was in the C2 forum. I'm afraid C2 is no longer supported and won't be getting any more updates.

  • The official Greenworks addon supports NW.js 0.60.0 in its most recent version. Why not update to that?

  • Moved to Scripting forum.