My discoveries whilst using SFML

[Dinocool]

Hi, i'm an avid developer currently working on a 2d mmorpg.

along my travels i have come to rest on the wonderful api that is SFML.

now i just wish to post a few troubles i've had with the engine

Firstly, decimals and rendering.

when drawing to the screen, the float x and y should be cast to int.

why?

well, if you don't you'll experience strange rendering, positional and tearing glitches. where part of the sprite tears, or is compressed.

IMHO this should be fixed, as for me atleast it was confusing that when i started moving my characters they all of a suden became distorted.

this should ALSO be applied to view co-ordinates, as this has the same effect.

I would also ask, why sprite's require float X and Y coordinates, as from my experience you cant have half a pixel on the screen, as that doesn't make any sense.

If float variables are needed, atleast have an option when drawing to use non-rounded variables, or explicitly in the documentation refer to this drawing behaviour.

Another issue i have had with SFML is the font system, which in my opinion is a bit retarded...

firstly, i don't see why you couldnt just add an option to disable smoothing for sprites, it took me all of 2 minutes to add the code to the SVN release. 2 MINUTES, and it fit into the rest of the API

font->SetSmooth(bool Smooth);

Heres the code if you are indeed to busy

(goes into font.hpp)

void SetSmooth(bool Smooth);

(goes into font.cpp)

void Font::SetSmooth(bool Smooth){
texture->SetSmooth(Smooth);
}

i mean, really?

Other then this i have no REAL issue with the engine, it has done what it was supposed to do, at perfect speeds.

and to this i thank you Laurent as i'm sure most of the SFML community does.

Please Reply people if you would like to point out my stupidity, i love to learn and love criticism

[K-Bal]

Firstly, decimals and rendering.

when drawing to the screen, the float x and y should be cast to int.

That's what I would recommend, too.

My proposal:

While drawing coordinates are turned into ints, but the objects keep their float positions internally.

[Laurent]

Hi

First thanks a lot for your feedback, I appreciate it. That's what makes SFML better and better

when drawing to the screen, the float x and y should be cast to int.

This can be fixed without casting coordinates to integers. I still haven't found a global solution which solves all the rendering issues (there really are a lot of them), but this particular issue is already fixed in the current SVN sources. At least that's what my latest tests showed ; feel free to test yourself on your own application to validate it

this should ALSO be applied to view co-ordinates, as this has the same effect.

If you zoom then pixels no longer match scene units. Actually one can perfectly display a region of the scene which is between 0 and 1 in coordinates. The same problem appears by just rotating a sprite, the coordinates that need rounding are the ones after all the transformations have been applied.
Your solution of integer coordinates is just a particular case when no transformation is applied at all.

From a less technical point of view, I can also argue that there are two separate spaces that are completely unrelated to each other: the scene space, which is where you draw your sprites, and the window, which is just a particular view of the scene. The point is that there's no reason to add a constraint on scene coordinates based on where they will be displayed. We could imagine rendering a scene to a more accurate media than the screen (like printing it in high resolution).
You would never think about pixels when rendering a 3D scene, would you? Well that's the same for 2D.

I would also ask, why sprite's require float X and Y coordinates, as from my experience you cant have half a pixel on the screen, as that doesn't make any sense.

Your point of view is not open enough
Like I said above, things are drawn in a scene, not in a window. The window and its pixels are just a less accurate view of the scene.

Think in terms of drawing entities in a world, not pixels on a screen. Any rendering artifact must be addressed by SFML internally, not by the public API.

firstly, i don't see why you couldnt just add an option to disable smoothing for sprites, it took me all of 2 minutes to add the code to the SVN release. 2 MINUTES, and it fit into the rest of the API

Many features could be added with 2 lines of code, that's not my main concern. For a feature to be added to SFML it must first proves to be consistent, relevant, simple and clean. This particular feature has still not been implemented because I can't see any useful usage for it. Non-smoothed fonts are just ugly.

I love criticism too, so don't hesitate to disagree on what I said

[_seb_]

Many features could be added with 2 lines of code, that's not my main concern. For a feature to be added to SFML it must first proves to be consistent, relevant, simple and clean. This particular feature has still not been implemented because I can't see any useful usage for it. Non-smoothed fonts are just ugly.

1- Maybe, smoothed fonts are not suitable for laptop displays and LCD screens.
2- If I want to use my own font, perhaps it's better to disable smooth texture.
3- As you said Laurent,

We could imagine rendering a scene to a more accurate media than the screen (like printing it in high resolution).

In this way, automaticaly smoothed fonts should be depreciated (but could be the default behavior).

4-

I love criticism too, so don't hesitate to disagree on what I said

SFML is already great like this. Add more and more features, IMHO, is not compatible with the "simple concept" of SFML. But I think this feature doesn't break any things.

[Dinocool]

This can be fixed without casting coordinates to integers. I still haven't found a global solution which solves all the rendering issues (there really are a lot of them), but this particular issue is already fixed in the current SVN sources. At least that's what my latest tests showed ; feel free to test yourself on your own application to validate it  

firstly, it's not fixed .

second of all i believe that as you said, the window and scene are kept seperate.

so when calling app.Draw, perhaps then the scenes position vectors are translated to int's

Non-smoothed fonts are just ugly.

Honestly mate, thats just like saying "i think that nonAA fonts are ugly and therefore will restrict you from using them." is it really upto you to decide that?? by adding one function you can pass that decision from you to the user, and thats where the decision should be. hell i wanted to make the font purple with pink spots and the functionality was EASILY there, i should be able to do just that. just because you dont like it doesnt mean it shouldnt be there.

[Laurent]

firstly, it's not fixed

So I'd really be glad to get a minimal code that reproduces the problem from you.

so when calling app.Draw, perhaps then the scenes position vectors are translated to int's

Like I said, it's the coordinates after transformations that need to be converted, and not always to integers.
I can't do anything about that. Unless I remove rotations / translations / scales / views from SFML

Honestly mate, thats just like saying "i think that nonAA fonts are ugly and therefore will restrict you from using them." is it really upto you to decide that??

Well, I'm not saying that I'll never implement a feature if I don't like it. All that matters is to know if people actually need it.
If many developers need ugly fonts, or if you show me that under certain circumstances non-smoothed fonts look better, then I'll be perfectly ok with that and I'll think more about implementing them.

[Nexus]

firstly, it's not fixed .

I think it is. Which version of SFML are you using? One of the main solutions was presented here.

If many developers need ugly fonts...

Probably, this won't happen too soon...