1. Anders Ruud
  2. love
  3. Issues


Issue #374 resolved

Adding the option of the alpha channel to newScreenshot

created an issue

Some users get confused when their screenshots are different from what they see on the screen, not realizing that the image actually includes the alpha channel.

I propose a minor change and addition to {{{love.graphics.newScreenshot}}}. By default, it should copy the buffer without the alpha channel (replacing everything with 255). The lover can then choose to copy the alpha anyway by passing {{{true}}} as the first argument to {{{love.graphics.newScreenshot}}}.

The code should probably be tested on different platforms before it would go into the repository.

Comments (3)

  1. hahawoo

    This seems to make a lot of sense, I'd predict this would be almost always the desired and expected default behaviour.

    This is probably crazy, but perhaps it would be more consistent to use a string instead of a boolean. Constructors with an optional argument that can be one of two options outside of love.physics, i.e. love.audio.newSource and love.filesystem.newFileData (I think that's all), use strings.

    Whether this is actually a better choice or not, I have no idea, I just thought I'd mention it. :D

  2. Alex Szpakowski

    glPixelTransfer isn't supported in OpenGL ES 2.0, so if LÖVE were to use that function to ensure screenshots have full opacity in desktop versions, it would have to have a different (and likely slower) method on potential future mobile versions.

  3. Alex Szpakowski

    For now it will use a plain loop to replace the alpha values with full opacity. If it's later determined that glPixelTransfer will always work properly on deprecated desktop GL, and newScreenshot is a bottleneck in someone's code, we could switch to that for non-ES versions of love.graphics.

  4. Log in to comment