Ashley's Recent Forum Activity

  • If you load the editor from editor.construct.net it always auto-updates. There's a complicated mechanism using a Service Worker to handle that which I think would be difficult to change, and besides I think it makes sense that the base domain always serves the latest stable release (it's not like a new user visiting for the first time wants to load an old release there). If you install Construct as a desktop app, it does exactly the same thing as the browser, so if you install from editor.construct.net that's still the update process you'll get.

    If you load an old stable release in the browser it does still notify you. I actually thought we'd already added a setting to cover that, but I must have forgotten. I've added a setting to turn off update notifications for the next release, so you can make sure loading old releases doesn't keep prompting you to update. Note however this does not affect the update process for editor.construct.net: as the actual files served there are updated, then it will still update you even if you turned off update notifications, and so the editor still also shows an update notification to tell you that's going to happen.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,824,247 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs