SetSmooth - default to false

[renton_django]

More of a minor config request than a feature request.

I think the Image SetSmooth feature should default to false. Most 2d developers try to be pixel perfect with their sprites and graphics, so trying to figure out why their sprites are blurry and scaled can be a bit of an obstacle to developers that are trying to learn SFML. Searching "SetSmooth" on the forums shows many cases of these issues.

It's an amazing feature, but I think it is too case specific to be turned on by default.

[Lupinius]

Signed. Wanted to post the same thing just now actually  :lol:
Also why does the smoothing even make the edges of sprites visible?

[Laurent]

I think the Image SetSmooth feature should default to false. Most 2d developers try to be pixel perfect with their sprites and graphics, so trying to figure out why their sprites are blurry and scaled can be a bit of an obstacle to developers that are trying to learn SFML

I'm not sure it is the majority of developers. I guess I should open a poll, and see the results.

Also why does the smoothing even make the edges of sprites visible?

I'm not sure, but maybe it is fixed in SFML 2.

[devlin]

Also why does the smoothing even make the edges of sprites visible?

You usually get that effect when using bilinear filtering and not having wrapping mode set to "gl_clamp" (i.e. gl_repeat or gl_clamp_to_border with a border-color set to a visible color) (if the texcoords go outside the 0.0 - 1.0 range or you rotate/scale the sprite)

[Nexus]

I think the Image SetSmooth feature should default to false. Most 2d developers try to be pixel perfect with their sprites and graphics, so trying to figure out why their sprites are blurry and scaled can be a bit of an obstacle to developers that are trying to learn SFML

I'm not sure it is the majority of developers. I guess I should open a poll, and see the results.

I agree with renton_django. There are again and again SFML users who stumble upon this (examples: 1 2  3 4 5 6 7 8 9, and that's just a small part I've found). In my opinion, the default behaviour should try to render 1:1, without applying any filters. In fact, I have mostly disabled SetSmooth() myself.

[Laurent]

There are again and again SFML users who stumble upon this (examples: 1 2 3 4 5 6 7 8 9, and that's just a small part I've found)

Ok but we don't how many there would be (asking for smoothing by default) if I changed. Could be more.

In my opinion, the default behaviour should try to render 1:1, without applying any filters.

The problem is that when you rotate or scale, it quickly becomes ugly without bilinear filtering.

And most of the topics you're referring to have the border problem, which is (normally) solved in SFML 2, without disabling smoothing.

[Nexus]

Ok but we don't how many there would be (asking for smoothing by default) if I changed. Could be more.

This is of course true, however the status quo is an indication that the semantics of SetSmooth() are not very intuitive for beginners. Even if they remain the same, you should probably emphasize them in the tutorials and documentation.

And most of the topics you're referring to have the border problem, which is (normally) solved in SFML 2, without disabling smoothing.

Okay, that's good to hear

We have already had a discussion about pixel-perfect rendering some time ago, is it somehow related to the smooth filter? Do rotated sprites become ugly when either the smooth filter or the pixel interpolation is deactivated?

[Laurent]

We have already had a discussion about pixel-perfect rendering some time ago, is it somehow related to the smooth filter?

Yes it is. I had a lot of fun trying to find an algorithm that makes both smoothed and non-smoothed sprites look good.

Do rotated sprites become ugly when either the smooth filter or the pixel interpolation is deactivated?

I don't use pixel interpolation anymore, I was getting unexpected bad results.

[Nexus]

Does that mean that the rendering of sprites with disabled smooth filter is actually pixel-perfect? Or are there other factors coming into play?

[Laurent]

Since I've disabled pixel interpolation, you can get pixel-perfect rendering only if the sprites's coordinates are aligned with pixels. And in any case, if you scale or rotate it you can't get pixel-perfect results; except in special cases like scaling by an integer factor, or rotating by a multiple of 90 degrees.

By the way, it's more "pixel alignment" than "pixel interpolation"
In fact we can say that pixel interpolation happens when I disable pixel alignment. I just realized that it was probably confusing in my previous posts.

[Nexus]

I have understood pixel interpolation like this: If a white point on a black background is offset by 0.5 (i.e. non-integral coordinate), you see two gray pixels. The other way would be rounding (aligning?) to integral coordinates, so that you see a single white pixel.

And I thought you would currently use "interpolation" (according to my above definition), right? Sorry for the confusion

[Laurent]

Ok yes, you're right. I've disabled my custom pixel rounding algorithm, now texels are interpolated if they fall in between two pixels -- this is the default OpenGL rasterization behaviour.

Hope everything's clear now

[Nexus]

Yes, thank you