Way to draw using normalized coordinates via sf::RenderTarget

[FRex]

Ditto.
Possible backwards compatible way could be another field in sf::RenderStates plus few trivial changes in sf::RenderTarget.

[Gambit]

Could you be more specific? Normals for what and why cant you use unnormalized values?

[FRex]

I mean normalized coordiates, SFML is actually doing a tiny bit of extra work to get you the pixel coordinates but 'support' for both exists: http://www.sfml-dev.org/documentation/2.2/classsf_1_1Texture.php#ae9a4274e7b95ebf7244d09c7445833b0

The problem is that all SFML code (aka. around 10 relevant lines in RenderTarget.cpp) right now uses pixel mode, so all texture coords that you use are interpreted as pixels.

You can normalize them yourself but it's tedious, backwards and requires you to know the size of the texture.

[Gambit]

I'm sorry, I'm not sure I fully understand. What's the problem with using CoordinateType::Normalized?

[FRex]

You can only use it for own OPENGL code.
You can NOT use it for drawing to sf::RenderTexture or sf::RenderWindow because they are always using Pixels, it's hardcoded in their (common) code.
Because of this, there is no way to create your own* custom drawable class that uses Normalized coordinates, which is pretty sad, considering that sf::Vertex gives us so much power and low-level access to design our own drawable classes already.


*drawables of SFML assume Pixels so you couldn't use them with Normalized even if Pixels wasn't hardcoded.

[thomas9459]

Are you referring to using RenderTarget::draw() with normalized coordinates, such as

sf::RectangleShape rectangle(sf::Vector2f(0.5, 0.5));
rectangle.setPosition(0.25, 0.25); // Remember that this sets the top left corner of the rectangle

window.draw(rectangle);
 

to produce a rectangle that is centered on the window and with half the size of the window? If so, you can accomplish this using views by using window.setView(sf::FloatRect(0.0, 0.0, 1.0, 1.0). If that's not what you meant, could you provide some example code to show exactly what you would like SFML to do?

[FRex]

I am talking about normalized texture coordinates.
It's a pretty basic concept in computer graphics (among other things): it means that instead of using texture coordinates in range from 0 to size, we use ones in range from 0 to 1.

TopLeft corner is (0, 0) in Pixels and (0, 0) in Normalized.
BottomRight corner is (size.x, size.y) in Pixels and (1, 1) in Normalized.

To get Pixels out of Normalized or other way around you just multiply or divide by size (which is what SFML does internally to give us Pixels, it sets a matrix in GL that divides x and y by respective texture sizes on each access to map Pixels into normalized coordinates, look at Texture.cpp).

The advantage of Pixels is that it's more intuitive for most people.
The advantage of Normalized is that it doesn't rely on texture size but on ratios (ie. you can draw a single 100x100 quad and map entire texture onto it, without knowing its' size).

A quad with these texture coordinates, in Normalized, covers entire texture, no matter the size:

sf::Vertex ver[4];
ver[0].texCoords = sf::Vector2f(0.f, 0.f);
ver[1].texCoords = sf::Vector2f(0.f, 1.f);
ver[2].texCoords = sf::Vector2f(1.f, 1.f);
ver[3].texCoords = sf::Vector2f(1.f, 0.f);

[Laurent]

You still haven't answered the question: why? Do you have a use case, or more complete explanations on why this would be beneficial to SFML?

[FRex]

As I said:

The advantage of Normalized is that it doesn't rely on texture size but on ratios

no way to create your own* custom drawable class that uses Normalized coordinates

The use case is not spectacular, I had to map entire texture onto quad and had to pass the size onto it somehow, since I couldn't just use 0,0, ..., 1,1 as coords and not care about texture (that'd come in render states anyway).
But I know it probably won't be accepted since it's not in SFML's definition of 'Simple' but at least I can't say I didn't try.

[Ixrec]

Going just on what you wrote on that post, it sounds like at some point you had to write "0, 0, texture.getSize().x, texture.getSize().y" and are asking for the ability to shorten that to "0, 0, 1, 1".  If so, that doesn't really seem like enough of a simplification to justify additional functions in the API.

I think Laurent's asking for a significantly more detailed and concrete argument.  Maybe some before/after code snippets would help.

[Laurent]

I think Laurent's asking for a significantly more detailed and concrete argument.  Maybe some before/after code snippets would help.

No, his description of the use case was detailed enough.

But I know it probably won't be accepted since it's not in SFML's definition of 'Simple' but at least I can't say I didn't try.

I don't know what others think about it, but to me it's probably not worth adding something to the public API.

[FRex]

The rule of thumb is: If a feature can easily be added on top of SFML without modifying the core library, it is probably not a good candidate to be integrated.

It's not a big deal but it is a limitation, and an artificial one that cannot be jumped over in any sane way.

I don't know what others think about it, but to me it's probably not worth adding something to the public API.

Then why is there Normalized already in the public API?

[Laurent]

Then why is there Normalized already in the public API?

You said it: for own OpenGL code. Look at the Texture::bind function:

static void bind(const Texture* texture, CoordinateType coordinateType = Normalized);

[FRex]

Considering I linked to it and read it's source before, I think I know that function.

I was just making a point: for sf::Vertex + sf::RenderTarget it's "too much additions in API"/"out of scope"/"not big advantage" to add one field to render states plus some insanely small internal changes, but it's okay to write a bind that also allows Normalized and expose that in the API.

Also, this functionality is redundant, you can get id of GL texture from sf::Texture and then use that to bind it however you want, and you might as well, since you are already doing GL calls, SFML is not blocking that possibility, sf::Texture::bind with Normalized is just a shortcut, not the only way.
On the other hand, using Normalized with sf::Vertex and sf::RenderTarget is not possible with SFML, nor GL.

[eXpl0it3r]

I was just making a point: for sf::Vertex + sf::RenderTarget it's "too much additions in API"/"out of scope"/"not big advantage" to add one field to render states plus some insanely small internal changes.

Maybe you could expand on this possible implementation a bit more, as one usually does in the open post of feature request (instead of writing "Ditto" and assume everyone knows exactly what you're thinking).

Also, this functionality is redundant, you can get id of GL texture from sf::Texture and then use that to bind it however you want

As you probably already know, I've no idea about all the GL magic, but last I checked SFML doesn't provide the actual OpenGL IDs, which exactly the reason why the bind functions were introduced. But maybe I understood that wrong in the past.