aseprite/api

drawImage() does not draw properly transparent colors

ppelikan opened this issue · 3 comments

We draw an yellow X on the Layer 2 (and the rest is on the Layer 1):
Screenshot_20230428_002504
Now if we want to draw all layers from Group 1 using API call drawImage() with an example code:

local layer = app.activeSprite.layers[1]
local bufimg = Image(app.activeSprite.width, app.activeSprite.height, ColorMode.RGB)
if layer.layers ~= nil then
    for _,l in ipairs(layer.layers) do
        local ce = l:cel(app.activeFrame.frameNumber)
        if ce ~= nil then
            bufimg:drawImage(ce.image, ce.position, ce.opacity) --, l.blendMode)
        end
    end
end

local new_layer = app.activeSprite:newLayer()
local new_cel = app.activeSprite:newCel(new_layer, app.activeFrame.frameNumber)
new_cel.image:drawImage(bufimg)

we get the following result on the new Layer:
Screenshot_20230428_002556

It seems that the transparent color was disregarded, and treated as any other color.
I would expect the yellow X to be drawn the same way as on the first picture.
Is it a bug of the drawImage() itself?

Aseprite version 1.2.40

Thank you for this detailed report. That is normal behavior in 1.2.40. But in the latest version (1.3rc2) we added blending options to this function at aseprite/aseprite@637632e.
We'll need to add some version compatibility statement when new options are added.

How can I ensure that merging layers works correctly?
I want to select some group, draw all its layers on top of each other and send them though websocket. Is it possible to achieve that without this artifact appearing?

in the latest version (1.3rc2) we added blending options to this function

Does it mean, that updating to this version and using BlendMode.NORMAL would fix this problem?

How can I ensure that merging layers works correctly?

With a script that compares images pixel by pixel:
Control image (created manually from two source images) VS image resulting from drawImage() (same two source images).

Does it mean, that updating to this version and using BlendMode.NORMAL would fix this problem?

Yes. But you don't need to add BlendMode.NORMAL as an argument because it's the default blend mode.