Ashley's Forum Posts

  • It would be extraordinarily wasteful if Construct loaded the same image 1000 times for 1000 Sprite instances. Therefore all Sprite instances share the same set of images. When you load an image from a URL, it replaces an animation frame in the shared set of images, therefore updating it for all of them. When you look at it that way, I think it works logically.

    The Sprite manual entry does note:

    All instances of Sprite objects share their animations. In other words, there is a single set of images comprising the animations which belongs to the object type, and these images are referenced by instances.

    To clarify the point about loading an image from a URL specifically, I've just added a note to that action:

    Note that as all Sprite instances share the same set of animations and frames, loading an image will replace the image for all instances of the object type. If you want to dynamically load images for individual instances, try adding animation frames and loading a different image in to each frame.

    That note advises what you can do instead. It looks like you linked to a thread about 2 years old, and I don't think dynamic animations were implemented back then, so you may have fallen in to the trap of digging up out of date information. It should already be possible to use dynamic animation frames to load images from URLs on a per-instance basis.

  • The error is "failed to fetch", which suggests some network request failed. Try looking in the browser console for a more detailed error message. If you send your project to supportgwm@construct.net we can also take a look.

  • You can load a specific release from the releases page. If you browse to editor.construct.net it will always serve the latest stable release.

  • Please report problems by filing an issue following all the guidelines. Things only mentioned on the forum are easily lost and forgotten, and it's not possible for us to investigate problems solely from exported projects.

  • It's hard to tell from just that. You generally will need to share an actual openable Construct project for anyone to be able to help you. All I can say is it looks like tempNickTeam1 and tempNickTeam2 are null.

  • How do I see the memory consumption of each sprite? In the debug screen I can only see the total memory consumption.

    Sprites aren't actually loaded individually - they are placed on sprite sheets and then an entire sprite sheet is loaded. If you right-click the project name in the Project Bar and choose Tools - View Spritesheets, you'll see the set of spritesheets Construct has generated for your project, including the approximate memory usage and download size per sprite sheet. (Those details can change after export though, depending on export settings.)

    Another question, I know there's a recommended maximum pixel size for each sprite (4096px). But if I put a smaller sprite on a tiled background, and increase it to one above the recommended size for the sprite (for example: 8192px), is that a problem?

    Just to be clear, because an earlier reply was incorrect: that's fine. So long as the source image is 4096 pixels or smaller, you can resize it as large as you like and it won't be an issue.

  • I'm afraid SDK v1 addons cause catastrophic compatibility problems and the risk of keeping them is unacceptable. Due to the lack of encapsulation, addon developers have written lots of addons that manipulate the internal details of the engine that were never meant to be used. If I merely rename something or move something around to better organise our code, it can break addons, causing problems for hundreds of customer projects, who then all contact support and blame us for breaking their project in the latest release. This has, and will, happen over and over again. In the long term all parts of the engine eventually change, and so eventually all such addons will probably break. It will leave us in the position of having to either stop making improvements to Construct, or break lots of projects.

    This is thoroughly understood stuff in the software industry. For these reasons no other professional tools allow unrestricted access to internal engine. The industry standard for decades has been to use encapsulation and enforce that only a specific documented API can be used. Then you can ensure everything keeps working in the long term, even when doing major internal upgrades, and even after the addon developer left the community many years ago. The only reason Construct ended up with a lack of encapsulation is historical reasons - basically JavaScript did not used to support it.

    I know this will be a painful transition but unfortunately I believe it is absolutely necessary to make Construct reliable and trustworthy in the long term. The next LTS release will be supported for another 18 months so there is still a long period of time that SDKv1 addons will still be continued to be supported in LTS.

  • IIRC Construct doesn't cache any project logic when you export, so it will regenerate all project logic on every export. If it isn't updating something correctly, it should be easy to prove it with a minimal project that you can file a bug report with. However I don't recall ever seeing such an issue with Construct.

    Honestly my best guess is that with large complex software projects, you probably forgot about something and have a bug in your own project logic, or made some mistake somewhere in your testing process. It's easy to do - I sometimes get mixed up with things like preparing Construct releases. There's a lot of moving parts and things like whether or not storage is clear or whether it's running in release vs. development mode are easy to confuse. In particular if you move it all over to a new fresh machine and it works the same, my best guess is it is actually working correctly.

    Other than that, based on your other thread, it sounds like maybe something weird is happening to your system. Try using a different machine for a while.

    That's the best I can do with telepathic debugging - our bug report guidelines are there because that's how to make sure issues get fixed.

  • As per layout-by-layout loading, when a layout starts, Construct has already loaded all the objects initially placed on the layout.

    If you dynamically create objects that are not initially placed on the layout, it's not possible for Construct to know when all of those have finished - after all, you could start such loads at any time. In that case it's up to your own event logic to determine when it's ready, such as by using the system memory actions.

  • There's several built-in examples that might help: take a look at Driving, Ghost Racer, and Vehicle switching.

  • What can I do if I sometimes feel that the arrangement of the sprite sheet is not "smart" enough?

    Automated arrangement is probably never going to be absolutely perfect, but my view is it's basically good enough. For it to not be good enough, you need to base the evidence on measurements. For example, what is the peak image memory usage of your game? These days if it's under 1 GB, it's hard to think of any device that could not run it outside of things like bottom-spec Raspberry Pis. Even low-end phones ship with 4 GB RAM these days. So why improve it if it's not a problem?

    It's like trying to improve the performance of your game when it already runs at 60 FPS on low-end devices. It's a case of job done - theoretically it could be faster, but nobody will actually have a better experience of the game. So why not spend your time on things that actually do improve the experience of the game?

    Does the engine still support the "texture batching" technology?

    Construct has sophisticated batching technology. If you make 30 instances of the same sprite, and they are all drawn together, Construct will issue a single draw call with a single texture specified. In many cases, Construct can issue a single draw call to draw multiple objects, providing they are from the same spritesheet. With the WebGPU renderer, if multi-texturing is enabled, it can issue a single draw call to draw multiple objects from any of up to 14 different spritesheets. On top of that, you can enable image deduplication on export to make sure even different objects with the same image only export the image once. It's a very well optimized part of Construct - modern devices can handle hundreds of thousands of on-screen sprites and still hit 60 FPS.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I went to did a demo of the game and it crashed on my laptop.

    Both WebView2 and NW.js use the Chromium browser engine so in theory they should work the same. If you could file an issue for a WebView2 crash (ideally with a minimal project - you could just fill it up with dummy video content if you need a lot of videos to reproduce the problem) then I'd take a look - anything that blocks people moving over to WebView2 is a priority for us to fix.

    But more importantly, I need to be able to save files like every game does to the UserFolder located in "C:/Users/UserName/AppData/Roaming/GameFolder/"

    The File System plugin supports that with the Windows WebView2, macOS WKWebView and Linux CEF export options, using the picker tag "<current-app-data>". (You can also use "<roaming-app-data>" but that's Windows only.) See the File System manual entry for more details.

    My only concern was that perhaps the downloaded content could be copied, kept and dissected even after the remote preview ended.

    In theory the content downloaded via Remote Preview could be copied and kept. You'd probably need a specialist tool though. If you trust your testers it's probably OK.

  • First of all it's worth asking: is this really a problem? Modern devices all have loads of memory, and it doesn't look like your project is that image heavy. So long as the peak memory usage is reasonable, then optimizing it is actually a waste of time - you may as well spend your time on something more significant.

    So is your peak memory usage actually a problem? If so the first place to look is our guide on memory usage which includes general advice on optimizing it.

    If you really want to adjust Construct's spritesheets, there are two things you can do: the main one is to adjust the project advanced setting Max spritesheet size. Lower maximum spritesheet sizes will allow finer memory loading granularity which can result in lower peak memory usage, but at the expense of efficiency (reduced runtime performance and increased download size).

    The second thing is to make sure you've organized all your objects on to layouts appropriately. Construct has an algorithm that tries to group objects used together on the same layout on to the same spritesheet, in order to avoid situations like having one spritesheet with content from several different layouts that are never used together. If your project doesn't abide by that (e.g. by placing everything on the same layout) then Construct doesn't have any clues about how to group objects together and so that algorithm will prove ineffective.

    I'm skeptical that any feature to manually adjust spritesheets would really be useful in practice - with its current design, Construct frequently discards and regenerates spritesheets as you edit your project. So any manual changes would likely be quickly reverted. Even if there were other ways to permanently specify how spritesheets were arranged, as you continued to edit the rest of the project and Construct continued to automatically regenerate other content, I'd imagine it would be easy to accidentally end up with a set of spritesheets that are actually less efficient than if you just left Construct to do it automatically - and that might be after having to spend a long time to manually tweak everything. It doesn't seem like a good thing to spend time on when designing your project, especially if the peak memory usage is not really a problem to begin with.

  • Remote Preview will download similar resources to an unminified export of your project. I'm not aware of any tool ever having been developed that could reverse even an unminified export back to a Construct project, but it is theoretically possible (although a lot of details would go missing, like comments in event sheets).

    If you export your project with advanced minification, it makes it far harder for anyone to reverse engineer it. I suspect (but don't know for sure) that it is infeasible to develop a tool to reverse advanced minified projects back to a complete Construct project - we've specifically designed it to make sure this approach scrambles all the key details of the project. I'd guess it's more convenient for pre-release testing to export an advanced minified copy of your project anyway, as the Remote Preview URL only works so long as you keep the Remote Preview window open, so your testers will have to load the project at the same time as you.

    I'd also point out NW.js is deprecated and is going to be removed from Construct in the next few months, although it will continue to be supported in the next LTS release to the end of 2026. It will be far easier to switch to the other export options before you release your project, since otherwise you risk losing things like Local Storage data. So I'd suggest switching over and using the File System plugin for local read/write functionality, as that will be supported indefinitely.

  • My advice is to add a JSON project file and load it with AJAX. Then you can use a dedicated editor for your JSON data without having to worry about how to properly escape JSON strings in expressions, which is quite fiddly.