Ashley's Forum Posts

  • It's intentional. It is just one of probably dozens of subtle trade-offs and heuristics in the spritesheeting system that we've carefully tuned over the years.

    The limit is arbitrary, but the goal is to avoid a worst-case scenario of a single small sprite image sharing a spritesheet with another sprite with loads of animation frames. For example imagine a small 50x50 image for a button on the title screen ends up placed on a 4096x4096 spritesheet which is entirely full of animation frames from the boss at the end of the game. Now to display that button on the title screen, it must load the entire spritesheet of mostly boss images, using a minimum of 64 MB memory for the entire spritesheet. If you imagine that happening another 10 times with different objects, now you are looking at an extraordinarily high memory usage of 640 MB for just a few buttons on the title screen - an appallingly inefficient result. This heuristic means the boss sprite gets its own spritesheet and avoids that happening. There could still be other unrelated shared content on the button's sprite sheet, but there are other heuristics to try to group objects likely to be used together on the sheet, and if lots of different objects are on the sheet it's more likely some of them will also be useful.

    In other words sprites with lots of animation frames tend to use a lot of memory, and in that case it's best to move them off to their own spritesheet so they are loaded separately for better memory loading granularity. This is also usually a good idea to reduce the download size as well, as modern image compression algorithms do a better job when an image has lots of repeating or similar content on it. We have an arbitrary threshold of 8 frames to switch to this mode. I prefer not to document such fine details of the spritesheeting engine, because we change such details from time to time, and if people assumed we used some specific number and then we change it, it might actually make their project less efficient. So my advice is to ignore such things.

    In case you're wondering if Construct could do a better job, I'd point out rectangle packing is NP-hard, which basically means an optimal solution is an unsolved problem in mathematics, and that's not even taking in to account other factors like memory loading granularity and download size optimization.

  • The Particles object doesn't support a lot of things, like animated particles, Z elevations, effects on individual particles, etc. That's what object mode is for - set it to create Sprite objects and then you can have all those things too.

  • The beta release r437 that just came out includes an updated Google Play plugin that is updated to use the games SDK v2. It was a difficult process to update it and it's tricky to test as well, so I'd appreciate any feedback and help with testing.

  • If all your settings have been reset, it is because the browser decided to delete all Construct's local storage (sometimes confusingly called "cookies", even though Construct just uses this to remember your settings locally and doesn't send it to any servers or use it for tracking). Unfortunately that is beyond Construct's control. Browser settings, or browser extensions, orientated around privacy or tracking may be responsible for occasionally clearing data, so changing any related settings may help. You can also try pressing 'Request persistent storage' in the About dialog to request that the browser tries harder to keep your data (but AFAIK that's still not a guarantee).

    If you were low on storage space I would guess the browser cleared storage to try to save space. The usual methods of clearing space on disk may help avoid that happening again, and Construct's 'Storage cleanup' dialog may help reduce how much storage Construct is using. It's also probably the case that the more storage Construct uses, the more likely the browser is to choose to delete its storage if the system is low on space.

  • FWIW in r437 which just came out the new limit of 1000 for decomposing concave polygons with the 'Fill poly' action is now implemented, which hopefully solves the immediate problem. Although I suppose if you go 10 times further it will hit the new limit.

  • The Taking screenshots example includes saving the image as a file.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The build service runs clean builds on every build so I doubt a reboot will help, but as it happens it was rebooted for other reasons just now, so you can give it another go.

  • I think this just happens because you changed a setting for the app to say the app uses advertising ID (you set that yourself in the Play Console), and then uploaded an app that does not use an advertising ID as the corresponding permission is not set (that depends on the plugins used in your app). So the error appears because it wants you to clear up the situation: either change the setting to say the app does not use advertising ID, or upload an app that does use the advertising ID. I don't think it's anything to do with Construct or the build server specifically.

  • Our guide on exporting to macOS should be up-to-date for the latest macOS versions. I just checked it with the latest macOS 15.4.1 though, and it does seem like macOS has made it even harder to run unsigned apps. The previous documented process of running sign-adhoc.command before running the app still works, but now in both cases it blocks running the script or app with a security warning. However if you open Settings and go to the Privacy & Security section and scroll to the bottom, there is an 'Open anyway' button you can use to bypass the security warning.

    You can also use the terminal to run sign-adhoc.command which appears to bypass the security warning, but this does not appear to work for running the app itself.

    I've updated the guide on exporting to macOS to cover these additional steps.

  • On Windows at least, the standard is for the confirmation button to be on the left. For example closing Notepad with unsaved changes has the 'Save' button on the left:

    Closing Chrome with unsaved changes also has the 'Leave' button on the left:

    Creating a condition or action is a multi-step process like a "wizard" where you can imagine moving right through the process as you advance and left as you go back. In this case the buttons are positioned to correspond to that process. It looks like Windows wizards usually have a button ordering of Back / Next / Cancel rather than Cancel / Back / Next like Construct has. I suppose we could change it, but then we'll trip up everyone who has been used to the 'Next' button on the right for the past 10+ years, as even Construct 2 had the same button ordering. And then such fundamental UI changes mean things like documentation screenshots, lesson plans, printed books etc. all suddenly become out of date, and updating them all is a huge job that is basically never fully done, so then you have ongoing confusion with out-of-date documentation. So sometimes I think it is better not to change things like this, even if it's a bit inconsistent, as the cost of changing it may well be higher than the cost of leaving it as it is.

  • It looks like we need to update Construct's plugin. Maintaining official plugins that integrate with third-party services outside our control always end up being a headache because of things like this, and this time is particularly difficult as the developer who originally wrote the plugin (Iain) has moved on. In general I think these kinds of plugins would be better off being third-party plugins - it would be a lot easier if we dropped support for it and left it to third-party addon developers to support instead (which we recently did with Game Center on iOS), or at least had them as open-source externally-installed addons (as we now have done for things like Steam integration). This would free up our time to focus on improving Construct itself instead of being obligated to do time-consuming updates for third-party services, especially the addon SDK basically exists specifically to allow such features to be developed separately. But I guess as it's built-in, appears to have significant usage, and this is time-sensitive, then we have to update it. So we'll look in to updating it soon.

  • I guess you're using Drawing Canvas and filling a polygon with 'convex' unchecked. As it can only really actually fill convex polygons, in this mode it does a highly complex and not particularly reliable algorithm to split a concave polygon in to a series of convex ones, and then fills those all separately. I guess you've run in to the limit of how far the polygon decomposition will go with that process.

    I'll increase the limit to 1000 for the next release which might help, but it might run in to other problems, like algorithmic inefficiency with too many points. You may have better luck trying to draw more smaller polygons, or keeping them convex - if you're trying to draw one gigantic concave polygon with loads of points, I'd say that's likely to be a problem.

  • In general issues only reported to the forum will not be investigated - we have the issue tracker for that. However in this case I think you've come across this Chrome bug.

  • I assumed this step would only take a fraction of a second and I'm surprised it would take that long. Could you share your project so I could take a look?

  • It's difficult to help from just that information - it should just work. Try disabling any browser extensions you have installed, as often the cause of mysterious problems is browser extensions interfering with how Construct works.