Why Does TiledBackground Support Unique Textures per Instance, but Sprite Doesn't?

Not favoritedFavorited Favorited 0 favourites
  • 5 posts
From the Asset Store
Controller Support ,TouchScreen Support , Keyboard Support , Action Platformer, Lots of Animations
  • How is it that you can load different images into multiple instances of the same TiledBackground object, and they each display their own image? But with a Sprite, loading a new image replaces it in all other instances.

    Does each TiledBackground instance have its own texture?

  • Initially all the tiledbg instances share the same texture from the type. They could very well have made loading another texture replace the texture of the type instead of just the instance.

    With sprites the type has the animations attached to it so basically all the instances share the same list of animations. So when loading an image it is simplest to just replace the image in the animation which affects all instances. Only replacing an image in the animation for just one instance would be much harder to do. Probably would require duplication of the animations per instance but not the textures.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I'm surprised there's no mention of this in the documentation.

    Also, unlike a sprite, TiledBackground "forgets" its new texture when the layout is restarted.

  • It's a very old part of Construct and has been like that for many years. I think the original thinking was that if you have 100 sprite instances, then you load 10 animation frames which they all load as individual images per-instance, then you just actually loaded 1000 images and you may well then run out of memory. Tiled Backgrounds are generally used with few instances with a single image so it is less likely to be a problem if they can have per-instance images.

    Even if we supported per-instance images for Sprite, it would mean solving that problem: there would need to be some way to actually say "share this image among these instances; share this other image among those other instances" as opposed to the naive and highly wasteful case of "every instance load its own copy of this image". I'm still not sure what that kind of design would look like in terms of the event system - I don't think there is precedent for that anywhere else in Construct. Perhaps it could happen automatically in the internal engine, but that might be a complicated feature to implement.

  • It does seem tricky to implement. My first thought would be a tick box on a Sprite's properties to change whether it does what it currently does with load url, or use new method of unique images (thus ALL instances either have the old way or the new way), but I assume that's not ideal as it's a "global" setting, not per instance.

    Thankfully we do have dynamic animations to fill the gap, although few bits needed to fully fill the gap, such as setting origin point or image points at runtime and such - iirc if you had origin point at mid, and then load url, it keeps origin at mid, which could be desirable.

    Definitely something I'd love to see, very interested in anything allowing "modding" support, such as loading external images.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)