Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • MoveTo basically ignores all the properties of the timeline, and just does the default MoveTo movement between each point on the timeline. The feature only exists so you can set up a path to be followed visually using timeline points.

  • Do the "split string" and "join string" actions have a field to define what is the separator ?

    Yes, of course.

  • So I tried opening that project and previewing it. The first preview takes a while as it has to render and compress ~2000 spritesheets, but during that time Chrome's task manager showed the memory usage of the editor hovering around 1GB, so it looks like it managed it OK. Then the preview successfully started. Then I closed the preview and started it four more times; each time worked fine and started pretty much instantly (as all the spritesheets are already prepared).

    So it seems to be working fine for me here. I think a bigger problem is Construct is estimating one of the layouts uses 5.6 GB image memory, which is colossal - many machines probably can't handle that much memory in one go. I have a high-end system with both 16GB system memory and 16GB VRAM. Lesser systems will probably crash. If that's the issue, then it's up to your game design - the blog post Remember not to waste your memory is old now, but its main point is still relevant.

  • I still don't think this is the right approach - naturally next there'll need to be inserting at index, deleting at index, appending to end etc. - and that is basically reinventing everything the Array object does.

    For the next release cycle I've added a "split string" action for Array, which can take a string like "1,2,3" and set the array to hold those three elements, and a "join string" expression, which can return a string like "1,2,3" of the array contents again. Then you can use all the existing Array features to set, delete, insert etc. items before returning a string again.