[1.1.87] Bug with sprite prototype size.

[ArsStels]

I've been struggling with this problem for days, where the sprite I create and send to chat is automatically scaled to the height of the line. I don't know how much it is in proportions, but for example it's 60 pixels. If I create a sprite that is 10 pixels high and 60 pixels wide, then in chat this image is stretched to 60*360. And I have no way to control this.
The scale parameter is completely ignored, shift works not as I would like it to.
For example, if you take any prototype, such as a recipe, item, technology, their icons are made with an offset and the offset works relative to the icon, not the screen. In the case of a sprite, the offset is relative to the screen. That is, if you scale the image, this offset is not scaled and is moved by the same number of pixels as it was. That is, images created with the offset just float away in different directions.
I tried using util.by_pixel(), but it didn't change anything and didn't help. I tried to create a sprite with layers, where the second layer (or the first one) is a completely empty square with a resolution of 60*60, in order to superimpose on top of those 10*60 and not get stretching of the image, but no, it also did not change anything.
It feels like the prototype sprite works completely differently than simple objects.

[Deadlock989]

I have also encountered this: sprites composed of multiple layers do not behave as expected when embedded in rich text and UI scale is anything other than 100%. I had to work around it by using a dummy item with layered icons.

[Rseding91]

Do either of you have some example of a sprite being "wrong" and how you think it should look so I can experiment?

[ArsStels]

Do either of you have some example of a sprite being "wrong" and how you think it should look so I can experiment?

Code: Select all

local flags = { "no-crop", "no-scale", "not-compressed", "mipmap", "linear-minification", "linear-mip-level", "group=icon" }

for i = 1, #Emojis, 1 do
  local emojiName = Emojis[i].name
  local width = Emojis[i].width
  local height = Emojis[i].height

  if width > 1620 or height > 2160 then
    error("\nOver the limited image size.\nERROR_CODE: 1\nYou have exceeded the maximum image size. Emoji should not exceed a resolution of 1620x2160. Your resolution:\n" .. width .. "x" .. height .. " for " .. emojiName, 2)
  end

  data:extend({
    {
      type = "sprite",
      name = emojiName,
      filename = "__chat-emoji__/graphics/icons/" .. emojiName .. ".png",
      width = width,
      height = height,
      flags = flags,
      priority = "no-atlas"
    }
  })

  local widthFragmentCount = math.ceil(width / 60)
  local heightFragmentCount = math.ceil(height / 60)
  local fragments = widthFragmentCount * heightFragmentCount
  Emojis[i].widthFragmentCount = widthFragmentCount
  Emojis[i].heightFragmentCount = heightFragmentCount
  Emojis[i].fragments = fragments
  log(serpent.block(Emojis[i]))
  local x = 0
  local y = 0
  local ostatokWidth = width % 60
  local ostatokHeight = height % 60
  local actualWidth = 60
  local actualHeight = 60
  local shiftX = 0
  local shiftY = 0

  for k = 1, fragments do
    if ((k % widthFragmentCount) == 0) and (ostatokWidth ~= 0) then
      actualWidth = ostatokWidth
      shiftX = 0 - math.ceil((60 - ostatokWidth) / 2)
    end
    if (k == (widthFragmentCount * (heightFragmentCount - 1) + 1)) and (ostatokHeight ~= 0) then
      actualHeight = ostatokHeight
      shiftY = 0 - math.ceil((60 - ostatokHeight) / 2)
    end
    log("name: " .. emojiName .. "_f" .. k .. "   shiftX: " .. shiftX .. "   shiftY: " .. shiftY)

    data:extend({
      {
        type = "sprite",
        name = emojiName .. "_f" .. k,
        filename = "__chat-emoji__/graphics/blank.png",
        width = 60,
        height = 60,
        layers = {
          {
            filename = "__chat-emoji__/graphics/blank.png",
            width = 60,
            height = 60,
          },
          {
            filename = "__chat-emoji__/graphics/icons/" .. emojiName .. ".png",
            x = x,
            y = y,
            width = actualWidth,
            height = actualHeight,
            shift = {shiftX, shiftY},
            blend_mode = "overwrite"
          }
        },
        flags = flags,
        priority = "no-atlas"
      }
    })
    if (k % widthFragmentCount) == 0 then
      x = 0
      y = y + 60
      actualWidth = 60
      shiftX = 0
    else
      x = x + 60
    end
  end
end

Blank - empty image with 60x60 pixels.

[ArsStels]

funcs/emojis.lua

[Deadlock989]

Do either of you have some example of a sprite being "wrong" and how you think it should look so I can experiment?

Two methods of making a 5-layer sprite, where the bottom layer is a 64x64 blank sprite (fully transparent) and the top 4 layers are a 64x64 white rounded-off square (with various tints) using shift offsets of {-8,-8}, {8,-8}, {-8,8} and {8,8}.

The way it "should look", composed as the icons property of an item, where the first layer's scale (the blank sprite) does not have a scale specified and the visible layers have a scale of 0.25 specified (because icon layers are still all relative to a size of 32x32 so to get a half-sized 64x64 icon, you scale to 50% of 50%). You get the same correct spacing and scales regardless of the UI scale or font size:

icon100.png (4.18 KiB) Viewed 728 times

At 100% UI scale

icon200.png (10.48 KiB) Viewed 728 times

At 200% UI scale


As a sprite, using layers, where the base layer has scale 0.5 and the four upper layers have scale 0.25 (the situation is not improved by using 1 and 0.5):

sprite100.png (5.74 KiB) Viewed 728 times

At 100% UI scale - shifts are wrong (too large) and layers look slightly clipped

sprite200.png (10.07 KiB) Viewed 728 times

At 200% UI scale - shifts are wrong (too small)

These example use a rich text image inside string-mod-setting localisations for a start-up setting's dropdown strings, but the same thing happens anywhere the rich text is used, e.g. in chat, flying text etc. If you want live examples of both methods, the current version (3.1.2) of the mod in my signature uses the item method for the setting (creating an otherwise redundant item just to have the menu option look the same as the other menu options, which all reference items or entities or single-layer sprites) and you can go back to version 3.0.12 of the mod (and find the right versions of the asset dependencies) to see the buggy layered sprite version. The reason I bothered with any of this is because the tint data already exists in Lua in the game - it references the rail block colour tints in utility constants - but in future I'm just going to compose these icons externally as a single layer sprite.