Texture Object

The update r133's image deduplication got me thinking: wouldn't it make sense to separate textures from game objects (sprite, tiled background etc.)?

Essentially, a texture object would only contain image data. Sprites, tiled backgrounds would then refer to those texture objects to pull images.

This way, you could manage all core image functionality in one place (think spritesheeting, compression/decompression, loading etc.), whereas sprites and other objects would only need to deal with positioning, resizing, tiling, z-ordering etc.

Just a thought. I am aware that I have little idea of how deeply wired Construct 2 is and that redesigning may already be too big of a task at this point, but it might actually make things easier in the future, who knows?

Construct 2 was simply designed the other way around. I think some users actually like the convenience of the fact a sprite actually is also its image, whereas in other tools you might have to import images separately, and then have a boring process where you have to link up an object and its animations to the right sequence of images.

The main reason images are usually separated from objects is to prevent duplication if you want two objects to use the same image. The new deduplication on export gains that benefit with our existing method, so I don't believe there's anything to gain from changing it any more.

I see.

Well, I was thinking more along the line of plugin development, to streamline it a bit, at least where images are concerned. The metholody you adopted may work best for you, but it ain't making it any easier for us mere mortals :(

We basically have reinvent the wheel over and over for each plugin that includes textures.

Do you mean the boilerplate code to handle images? Wouldn't you still need that regardless of where textures were stored?

+1 on image be linked or updated, and not reside inside the folder.