Graphic artifacts when using RENDER_SCALE_QUALITY

I brought this up several months ago.? SDL_BlendMode is defined as a bitmask (values of 1, 2 and 4), but passing the OR of the Blend and Add parameters (3) doesn’t work, when it should.

Nothing was done to fix this.

It ought to be redefined as a simple enum, with a value of 3 performing additive blending.

MasonOn Tuesday, January 28, 2014 12:23 PM, Alex Szpakowski wrote:

A whole new function isn?t needed, just a new SDL_BlendMode enum (and implementations in the backends of SDL_Render.)

It should probably be pretty trivial to implement if anyone wants to take a stab at it - although it seems a bit late to add features for 2.0.2 specifically.

Alex Szpakowski wrote:

You should use a premultiplied alpha blend mode instead of additive or ?normal? alpha blending. SDL_Render doesn?t support this directly though. In OpenGL it would be this:

glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

whereas ?regular? post-multiplied alpha blending is this:

glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

I have no idea how to make these calls and when I should do it.
Does it need to be done for every texture?

Gerry JJ wrote:

Den 27. jan. 2014 21:42, skrev ronkrepps:

When drawn with nearest neighbor scaling they look fine.
When drawn with linear or best the color (even though it’s alpha value
is set to 0) is drawing no matter what around the border of everything.

In short, this happens because the transparent pixels still technically
have a color even if you can’t see it, so the surrounding pixels are
blended with that color.

There’s something I don’t understand though. Is it common practice to do
like you said and make sure all of the transparent areas are set to a
similar color before setting the alpha value to 0? That seems like a lot
of extra work that just doesn’t make sense.

You can also solve it by using premultiplied alpha. When saving (or
loading) your textures, multiply the rgb values by the alpha value for
all the pixels (leave the alpha value as is). When drawing, instead of
"normal" alpha blending, use additive blending. That way, transparent
pixels literally contribute nothing when blended.

-g


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

How could I save or load the textures as you are suggesting?

Some additional info…

Here is what I tried and I’m sure I messed this up but…

Changed the SDL_BLENDMODE enum to the following:

Code:
typedef enum
{
SDL_BLENDMODE_NONE = 0x00000000, /< no blending
dstRGBA = srcRGBA */
SDL_BLENDMODE_BLEND = 0x00000001, /
< alpha blending
dstRGB = (srcRGB * srcA) + (dstRGB * (1-srcA))
dstA = srcA + (dstA * (1-srcA)) */
SDL_BLENDMODE_ADD = 0x00000002, /< additive blending
dstRGB = (srcRGB * srcA) + dstRGB
dstA = dstA */
SDL_BLENDMODE_MOD = 0x00000004, /
< color modulate
dstRGB = srcRGB * dstRGB
dstA = dstA */
SDL_BLENDMODE_PREMULTIPLIED = 0x00000008 /**< new test mode */

} SDL_BlendMode;

In SDL_render_gl.c changed the switch statement in GL_SetBlendMode() to the following:

Code:
switch (blendMode) {
case SDL_BLENDMODE_NONE:
data->glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
data->glDisable(GL_BLEND);
break;
case SDL_BLENDMODE_BLEND:
data->glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
data->glEnable(GL_BLEND);
data->glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
break;
case SDL_BLENDMODE_ADD:
data->glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
data->glEnable(GL_BLEND);
data->glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE, GL_ZERO, GL_ONE);
break;
case SDL_BLENDMODE_MOD:
data->glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
data->glEnable(GL_BLEND);
data->glBlendFuncSeparate(GL_ZERO, GL_SRC_COLOR, GL_ZERO, GL_ONE);
break;
case SDL_BLENDMODE_PREMULTIPLIED:
data->glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
data->glEnable(GL_BLEND);
data->glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
break;
}

Rebuilt the sdl2 library and using the newly rebuilt lib/dll I added the following code:

Code:

SDL_SetTextureBlendMode(texturefile, SDL_BLENDMODE_PREMULTIPLIED);

I also tried:

Code:
SDL_SetRenderDrawBlendMode(renderer, SDL_BLENDMODE_PREMULTIPLIED);

After trying these things: nothing changed

Here’s what I don’t understand. I created the following image:

[Image: http://i.imgur.com/2kwVot9.png ]

When I apply no SDL_BLENDMODE flag to the image or when I apply SDL_BLENDMODE_BLEND with the following:

Code:

SDL_SetTextureBlendMode(cloudbox, SDL_BLENDMODE_BLEND);

I get the bordered result: [Image: http://i.imgur.com/eferkhX.png ]

But when I apply the following flag:

Code:

SDL_SetTextureBlendMode(cloudbox, SDL_BLENDMODE_NONE);

I get the following result: [Image: http://i.imgur.com/uNeZcOf.png ]

It’s perfect… but how is it even working if the blendmode is set to SDL_BLENDMODE_BLEND how is it drawing the transparent areas correctly? And why is this one image not drawing the dark border?

[…]
[…picture with unwanted gray outline…]
[…]

This happens because the combination of blending and magnification
filtering causes the color of the transparent pixels to leak in
through the magnification filter.

To avoid this, you need to have your graphics application save the
color of the transparent pixels - even if they’re supposed to be
completely invisible. And of course, for that to work properly, you
need to make sure those pixels actually are the same color as the
pixels around the edge of the object. That is, if you remove the alpha
channel in the application, the transparent areas should become blue,
in this case.

Or, you can add some code to your loader that tries to fix this, but
that’s not entirely trivial to do correctly in every case.On Tue, Feb 4, 2014 at 11:44 PM, ronkrepps wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

David Olofson wrote:

This happens because the combination of blending and magnification
filtering causes the color of the transparent pixels to leak in
through the magnification filter.

To avoid this, you need to have your graphics application save the
color of the transparent pixels - even if they’re supposed to be
completely invisible. And of course, for that to work properly, you
need to make sure those pixels actually are the same color as the
pixels around the edge of the object. That is, if you remove the alpha
channel in the application, the transparent areas should become blue,
in this case.

Or, you can add some code to your loader that tries to fix this, but
that’s not entirely trivial to do correctly in every case.

Others have told me that I could edit the way I “load” the images and actually premultiply when loading them. This is what I’m trying to figure out. I am using SDL_Image to load the png’s but I don’t see any way to do it with that library. Instead I may have to use another library that has the premultiply option? I know there is some information about it in the libpng manual but not much. Surely someone has done this before?

I think pre-multiplyed alpha has nothing to do with scaling artifact. When scaling is performed, additional pixel has to be created using color value from surrounding pixels, and that causes the problem, not just the alpha function or alpha channel whatsoever.

mr_tawan wrote:

I think pre-multiplyed alpha has nothing to do with scaling artifact. When scaling is performed, additional pixel has to be created using color value from surrounding pixels, and that causes the problem, not just the alpha function or alpha channel whatsoever.

According to some of the info in this thread and a couple others I’ve read I have to do two things:

  1. Load the image with premultiplied alpha
    &

  2. Render with

     	glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
     	glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
    

I’m not sure how to load the image with premultiplied alpha though.

[…]

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

I’m not sure how to load the image with premultiplied alpha though.

Premultiplied alpha is primarily a performance optimization, so you
can use the above instead of this:

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

However, it actually does eliminate this artifact as well, because
what you do is mask out the background (the GL_ONE_MINUS_SRC_ALPHA
part), and then apply the texture using additive blending - and adding
black means “no operation!” Most importantly here, this means that
interpolating from any color towards black fades towards “no
operation”, rather than towards black.

I don’t know if there is any feature to premultiply alpha when
loading. If not, you’ll have to process the pixels of the surface
yourself; load as 32 bit RGBA with a specific byte order, multiply R,
G and B with A.

You could probably use SDL to alpha blend the image over a black
background, but you still need the alpha channel for the
GL_ONE_MINUS_SRC_ALPHA part, so I don’t think you can avoid some pixel
level coding there.

As to the alternative; full alpha blending, I’m not sure PhotoShop and
other applications actually can do the right thing. (I’m seeing a
lot of complaints about this on the 'net.) In GIMP, you can check the
"Save color values from transparent pixels" when exporting to PNG, and
it’ll work just fine - provided the original image is correct,
obviously! Usually not a problem, as antialiasing from selections etc
is implemented on the alpha channel, but it’s easy to get it wrong
with pixel art, where you basically use alpha as a 1 bit channel. If
you remove the alpha channel in GIMP, you’ll see the color information
in those transparent pixels. I’m not sure what PhotoShop does, but
apparently some applications automatically set all zero alpha pixels
to white or black.On Wed, Feb 5, 2014 at 5:21 AM, ronkrepps wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

It?s likely not any kind of meaningful performance optimization at all, on desktop hardware at least.

Premultiplied alpha is generally used for reasons other than performance. Blending correctness (e.g. getting rid of ?fringes?), better image compression, and advanced blending techniques (going between additive and alpha blending without changing blend modes) are a few reasons.


http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Premultiplied%20alpha]]
http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx
http://blogs.msdn.com/b/shawnhar/archive/2010/04/09/how-shawn-learned-to-stop-worrying-and-love-premultiplied-alpha.aspx
http://blogs.msdn.com/b/shawnhar/archive/2009/11/07/premultiplied-alpha-and-image-composition.aspxOn Feb 5, 2014, at 4:47 AM, David Olofson wrote:

On Wed, Feb 5, 2014 at 5:21 AM, ronkrepps wrote:
[…]

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

I’m not sure how to load the image with premultiplied alpha though.

Premultiplied alpha is primarily a performance optimization,


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[…]

True, that aspect is probably completely irrelevant to most of us
these days. It used to matter when you could still find machines and
devices without 3D accelerators. :wink:

I don’t think there is such a thing as a not meaningful performance
optimization in an AAA engine though, and I don’t think there ever
will be. Hardware gets faster, but people want more out of it - and
now they’re selling 4K displays… o.OOn Wed, Feb 5, 2014 at 9:54 AM, Alex Szpakowski wrote:

It’s likely not any kind of meaningful performance optimization at all, on
desktop hardware at least.

//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

I guess I just need to understand this on a lower level.
Is it not fixable without using just some SDL code or must it be modified.

I kind of understand what you are saying but I just thought there wouldn’t be an issue doing it with just SDL code.

I guess I just need to understand this on a lower level.
Is it not fixable without using just some SDL code or must it be modified.

Depends on the tools you use. I’m not sure what you’re using, but I
know some applications can’t get it right. What you need to do it
without post processing tools/code is PNGs with correct color
information in the transparent pixels. Then you should be able to use
"full" alpha blending without getting these artifacts.

If all else fails, you could use GIMP to fix it manually; import the
image, convert alpha to selection, fill with the color of the edge
pixels (provided it’s a single color all the way around - or you’re in
for some manual work), delete selected area (this is where you get
transparent pixels with the correct color), save as PNG with color
information in transparent pixels.

I kind of understand what you are saying but I just thought there wouldn’t
be an issue doing it with just SDL code.

One would think so, but these things aren’t as trivial as they may
seem at first, and many of the tools we use weren’t really designed
for game development and the like in the first place, so there are
almost always glitches at various places in the tool chain…On Wed, Feb 5, 2014 at 7:00 PM, ronkrepps wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

I like to “green screen” all of my PNG source stuff as you can see in my
code. Also, I don’t trust what comes from the file as far as propagation so
I also redundantly set the green screen . I like this as A best practice
because the green shows up nicely when there are problems and the edges of
my black outlined images always turn out better . So this is me, sharing a
best practice

where exactly is RENDER_SCALE_QUALITY defined in SDL documentation?
Can’t find it.

http://wiki.libsdl.org/CategoryHints#HintsOn Sun, Feb 9, 2014 at 5:17 PM, mattbentley wrote:

where exactly is RENDER_SCALE_QUALITY defined in SDL documentation?
Can’t find it.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The original alpha edge problem noted in this thread still exists in my test today on a Mac and Linux.

I see this as a fundamental mistake in the way alpha blending is handled.

To me, the various comments about a hack to ‘set the color of transparent edge pixels’, should be disregarded as an absurd workaround.

How, exactly are we supposed to scale a game to fullscreen without nonsense hacks? Doesn’t this mistake in SDL break basic use cases across the board where core quality is concerned?

If a person doesn’t use SDL, and is writing code more directly with the gpu in a modern approach, then compositing one alpha image on top of another and scaling it to fullscreen with a textured quad, is a trivial matter and could be considered a very typical situation that I do all the time.

Why then, is this fundamental component implemented incorrectly, and will anything actually be done about it in this community? Does this community take core problems like this seriously?

I also noticed in another somewhat relevant thread, how Mason appeared to be fighting warped cultural ideologies, and unable to convince the people with rational dialog:


The threads read to me this:
It is not that the culture is merely stupid, unthinking, or limited in attentional effort or time, but instead it sounds like the ideologies are so warped and specific, that basic wrong notions are elaborated with enormous detail and clarity, so that the excuses for why things are wrong today, become fortified and indisputable. Thus, irrational things continue to exist. Now, someone please tell me, how such situations can ever be overcome? Certainly this type of mental phenomena plagues the developer culture at large and not just SDL.

Surely, even my post may be as fruitless as Mason’s attempt at shining light on the absurdities going on in the culture, but how can we move on from this era, unless these incorrect mindsets and misplaced ideologies are confronted head on as irrational and done away with? As long as the cultural mindsets continue like this, how can we expect developer communities to ever meet and sustain higher standards of quality and re-establish strong foundations? Even if a new fork were established, if people from this same cultural tribe of mindsets became dominant participants, then it would merely end up back in the same current mess.

Perhaps, very few people even understand what the real foundational issues are here, how they came about, and why the cultural trends sustain that type of result, but if anything, I would like to see people speak out more like Mason, and if they have no other choice, to gather in a separate community that holds higher standards for essential elementary things, compared to what appears to be the majority population of today.

Every time, I try to keep an open mind and sample a public library like this, I run into these same type of problems, and can only make these type of wide spanning degrading conclusions about the culture, and resort to going back to doing everything myself at the lowest level possible.

If we are ever to work together collectively and achieve the fundamental standards of quality of this kind, I can only imagine that the current majority group would either have to change their beliefs to Mason’s, or be prevented from participating in our minority culture. Because, as it is right now, when both cultures try to exist in the same space, the warped majority culture is overriding the minority of higher standards and destroying it completely.

If anyone thinks this set of conclusions is wrong, then please tell me how to perform this basic scaling in SDL without nonsense hacks, and I will sincerely apologize for not reading and testing thoroughly enough.

Hi
There is no problem in the SDL.
This is a known problem that everyone faces, from indie developers to AAA studios like Rockstar.
Use premultiplied alpha if you want to avoid problems.
And if you’re interested, read http://www.adriancourreges.com/blog/2017/05/09/beware-of-transparent-pixels/

1 Like

But, can you point to the SDL functions to control it?

I had spent the entire day searching only to find people from a number of years ago, either facing this problem and proposing absurd hacks like this old thread, or saying that SDL does not expose control of this. (That one would need to drop into OpenGL/ Metal/Vulkan/DirectX directly)

If you accept that it is such a common and fundamental thing, and are not adopting a cognitive bias on the topic, don’t you think it is strange that the documentation and forum history make it seem like SDL does not account for this? Shouldn’t such a thing be implemented and then clearly documented?

A search from as recent as 2018 returns your very own thread rmg.nik, where you failed to find built-in control of this in SDL, and instead manually altered every pixel on the CPU (dare I not derail the topic further to state that your chosen solution is not even on the GPU and is considerably slow enough to matter)

I hope you can understand and differentiate what I’m saying are the real issues here with the way this has been handled by the SDL development community.

There are several ways to do this.

  1. Use texture packer with padding and pixel bleeding (e.g. https://www.codeandweb.com/texturepacker, https://github.com/wo1fsea/CppTexturePacker etc).
  2. Use pre-multiplied alpha and texture packer to export texture with pre-multiplied alpha.
  3. Pre-multiply the alpha when loading the texture into memory. This increases startup times, but you don’t need packers at all.
    Code sample
SDL_Surface* sfc = IMG_Load("image_filename.ext");
if (sfc->format->BytesPerPixel == 4)
{
    Uint8* pixels = (Uint8*)sfc->pixels;
    for (int y = 0; y < sfc->h; ++y)
    {
        for (int x = 0; x < sfc->w; ++x)
        {
            int index = y * m_surface->pitch + x * m_surface->format->BytesPerPixel;
            SDL_Color* target_pixel = (SDL_Color*)&pixels[index];
            target_pixel->r = (Uint8)(255.0 * (target_pixel->r / 255.0) * (target_pixel->a / 255.0));
            target_pixel->g = (Uint8)(255.0 * (target_pixel->g / 255.0) * (target_pixel->a / 255.0));
            target_pixel->b = (Uint8)(255.0 * (target_pixel->b / 255.0) * (target_pixel->a / 255.0));
        }
    }
}
SDL_Texture* tex = SDL_CreateTextureFromSurface(renderer, sfc);
SDL_FreeSurface(sfc);

SDL_BlendMode pma_blend = SDL_ComposeCustomBlendMode(
    SDL_BLENDFACTOR_ONE, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD,
    SDL_BLENDFACTOR_ONE, SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BLENDOPERATION_ADD
);

SDL_SetTextureBlendMode(tex, pma_blend);
1 Like