Scale factor in Atlas settings

Feature requests
3

After the conversation in DM with @dasannikov I think, I understand what he meant and what benefits of this feature. I’ll try to explain.

  1. Would be great to have scale option for atlases when a developer can set X and Y scale for all images inside the atlas. (X and Y separately just because sometimes you wanna compress image only in one measurement, it depend on image)
  2. Editor/bob get this scale and apply it to images and generate atlas with downscaled images.
  3. In runtime (or in scene editor) when we take sprite we calculate size as real_sprite_size_in_texture.x/atlas_scale.x and real_sprite_size_in_texture.y/atlas_scale.y and use this sprite with upscale.

Real life example:

  1. For example, we have background 1200x1200, when we add this background into atlas we have 2048x2048.
  2. We set the atlas scale to x = 0.8 y = 0.8 because we know that this quality good enough for us.
  3. Size of the image recalculates as 1200*0.8 = 960, as result we have 1024x1024 atlas with 960x960 image inside
  4. But in the game, it will be the original sprite size because when the engine takes the size of the sprite it calculates as 960/0.8 = 1200.

What the benefits:

  • Simpler pipeline for resource preparation because you all the time have original resources in your project and downscale them only in the build step.
  • Possibility to build different builds for different resolution: just iterate all atlases and set the scale to scale*0.5 (or another scale) in the pre-build step instead of rescaling everything everywhere.
  • in pair with Resource Property good solution for retina workflow

Open questions:

  • what to do with other types of resources (tilemaps, fonts, something else?)
  • we have some other way to have the same result for GUI (manualsize mode) and in Spine (we take sprite size from the json of animation as I understand), but it seems like this “atlas scale solution” will not conflict with both of those and will work as the addition for the existing systems.

P.S. It is not an announce of the new feature. This is an explanation of the @dasannikov idea.

(I think might be one more possible solution for our internal DEF-2058 issue about retina graphics content workflow)

6 Likes