Image deduplication of flipped/mirrored frames?

0 favourites
  • 3 posts
  • The very cool image Deduplication of sprites was introduced in r133.

    Yesterday, I was testing and playing with it for another reason when I noticed that frames of a sprite that are *exact* mirroring or flipping of another frame are still included as a separate and unique frame in the generated spritesheet.

    I am curious if there is a specific reason for this (as deduplication algorithms normally also look for these in order reduce the size of the resulting spritesheet even more) or this may get implemented in the future.

    Once again, thanks a lot for this feature.

  • The main reason is we have to change the rendering logic to deduplicate mirrored/flipped versions of frames, which makes it a little more complicated than just sharing an image between multiple objects (it has to become a reference to an image, plus a transformation to apply to it). The transformation has to work in both renderers (and I'm not sure off the top of my head if canvas2D can do that straightforwardly). We could add other transformation checks like simple rotations, but that adds further complication. Usually most features are a trade-off to maximise both straightforward engineering (which isn't too time consuming) plus utility to end users. I think this is a case where we've achieved most of the utility with the minimum of complexity.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Yeah, I guess it is always more complicated than it looks from the outside.

    Rotation and zooming have the added complexity that they are not "perfect" transformations as pixel artifacts may appear (which is not the case with simple flipping/mirroring).

    In any case, thanks for the info and for this feature

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