VertexArray UV coords.

[Calx]

Hi

Regarding VertexArray:

Texture coordinates are defined in pixels (just like the textureRect of sprites and shapes). They are not normalized (between 0 and 1), as people who are used to OpenGL programming might expect.

Would someone be kind enough to explain this decision to me? As the statement above in the (brilliant, btw) documents admit it's at odds with basically every other application, framework and workflow I've ever used. Was there a reason to go against the grain on this one?

Just to reiterate, I'm not complaining, just looking to further understand the reasoning behind this.

All the best

Dave

[Laurent]

If you haven't worked with OpenGL before, I think it's more natural and intuitive.

[Calx]

Interesting. For what it's worth I think if you've come far enough that you're setting up your own vertex buffers, you're probably not going to struggle with the concept of UV's being normalised.

[Laurent]

Why would you "struggle"?

Additionally, it's consistent with the textureRect property of sprites and shapes. Nobody ever complained about this one, so why would that be different for texture coordinates?

[Calx]

Why would you "struggle"?

I don't think you would, that's entirely my point.

Additionally, it's consistent with the textureRect property of sprites and shapes. Nobody ever complained about this one, so why would that be different for texture coordinates?

I think I've misjudged who you're aiming SFML at. I just wanted to do less GL/Windows boilerplate and saw SFML as a great option for exactly that - I wasn't expecting to find time-honoured approaches to be different to literally every other thing out there in the name of making stuff intuitive for beginners. I understand your stance, I just think it makes it less attractive for me.

[Laurent]

SFML is a self-contained API, with its own design. It's not an OpenGL wrapper. So yes, you may be disappointed by its API if you expected it to ease your OpenGL development.

[Calx]

I'm not looking for a GL Wrapper, it's the actually the classes you mentioned that interest me, (which incidentally is exactly where I would expect to find per pixel values as opposed to normalised) - It begs questions as to what happens in the vertex shader? Where are my values re-interpolated back to 0/1 space. These are all questions I came here looking to understand a bit better, and discuss. I'm interested in why you have made these design decisions, I'm not suggesting you've done anything wrong, or that you change anything.

So, the real disappointment here is only your continual pissy tone. Which, (from what I can gather from Googling questions about the API and reading a decent cross-section of your replies) seems to be par for the course here. It's a shame that SFML fails to provide the same friendly learning environment so successfully provided by the likes of Unity, Processing, Cinder, OpenFrameworks etc, cos unlike some of the aforementioned you have excellent documentation and reference available.

[eXpl0it3r]

Just to reiterate: SFML aims for a generally intuitive API, as such certain decisions will not be lined up with other technical APIs (e.g. non normalized coordinates, non radian rotation angles, etc.). Some will like, some will not, but this is just how it is (for now).

So, the real disappointment here is only your continual pissy tone. Which, (from what I can gather from Googling questions about the API and reading a decent cross-section of your replies) seems to be par for the course here. It's a shame that SFML fails to provide the same friendly learning environment so successfully provided by the likes of Unity, Processing, Cinder, OpenFrameworks etc, cos unlike some of the aforementioned you have excellent documentation and reference available.

It's something entirely up to subjective interpretation. I think neither you nor Laurent used a "pissy tone", but if one wants to, it's totally possible to argue either way. It's often hard to properly understand the meaning of a statement by just reading the text online. People come from different culture and they may not natively speak English, as such it often leads to misunderstandings/misinterpretation of statements.
We're riding a very strict line when it comes to API changes and feature discussions, which often goes against people's liking and makes them see SFML as evil, because we don't bend the library to their ideas. It may be something that will take away a bit of SFML's popularity and maybe loud people can damage some of SFML's image, but it's one of the only reasons why SFML's API design has been solid and well thought out for years.

Only in your last post, I see the real questions you want answers for. How should we be able to provide answers to your questions, if you don't ask them in the first place?
So maybe we can look beyond personal likes or subjective text interpretation and can come to technical questions and discussions now.

[Calx]

Only in your last post, I see the real questions you want answers for. How should we be able to provide answers to your questions, if you don't ask them in the first place?

Well, no. My initial question was clear, and was answered, defensively, and so didn't really invite any further conversation. I've no interest in API changes, I've no interest in feature requests, I was just opening a dialog about the design decision, but honestly I genuinely don't care that much, i'll just use something else / nothing. It's only a Sprite handler after all.

All the best

Dave

[Laurent]

I don't get why you suddenly became aggressive. I tried to answer your question with simple yet complete answers ("natural and intuitive", "consistent with the textureRect property", "own design", "not an OpenGL wrapper"). I never meant to have a "pissy tone", and if that's what my replies look like, then I'm truly sorry because that were not intentional -- it doesn't help when you reply in a foreign language.

The points listed above are my answer to your question, and of course I'm open to further discussion (as usual when it comes to design choices).

Thanks for your feedback anyway.

[Calx]

I wasn't aggressive. Your replies came across as dismissive, that's all. But let's chalk it down to language, there's certainly no need for an apology, but thanks all the same. I've not actually offered any feedback on the library as a whole either, but having read the books, and used the library extensively I'd offer the following:

Adopt industry standards where they wont interfere with your overall vision for the project - i.e here, where any user coming from literally any other framework or application I'd expect to find UV coordinates normalized, and anyone who uses this framework from a no knowledge start point will then go on to be confused when they find the situation everywhere else to be different.

Simple Vector maths library, I realise this is now a pretty ancient debate and I've read both sides, but honestly, SFML will continue to feel incomplete until it does this. Your audience is (probably) mainly 2D pixel graphics style games on the whole so why not provide the basic maths for dealing with that. I get that it's a media library, but you offer Sprites (quite game specific, no?), but not Pi or a few simple operator overloads for working with vectors?

Anyway, thanks for your time, and for the effort you put in to SFML.

Dave

[Elias Daler]

Maybe it's a bit off-topic, but what are some benefits of UV coordinates compared to absolute coordinates? Is it mostly because with UV you can scale your texture however you want and get the same results? Doesn't UV cause some problems due to stuff being stored as ratio (e.g. x / width) instead of just precise coordinate on a texture?

[FRex]

I wanted that 3 years ago too. It's a tiny change to have it in SFML but it's also such a tiny and niche feature that no one is going to die over it not being in SFML. The benefit is that you don't have to care for the size of the texture, it's really a quality of life thing to have, it's super minor, as minor as the unsigned ctor for sf::Color was.

[DeathRay2K]

That's a pretty important one. I ran into the issue implementing high DPI assets: it wasn't possible to simply swap out the textures with higher resolution versions, instead I had to convert from the expected texture size to the actual texture size.
It isn't that big a deal but it is something of a hassle. Ironically, the easiest way to deal with it is to store UV coordinates for everything and only convert to pixels when SFML needs it.

Starting out, I liked the way SFML handled that, so I didn't have to worry about calculating UV coordinates when I knew my textures in pixels. Now though, it is a bit annoying to have to convert to pixels and know that it's just getting converted back to UV coordinates.
The one potential problem with UV coordinates is that they are floats, which means they're going to be less exact than integers, but that problem is exacerbated by converting between coordinate systems.

Maybe it would be best if texture coordinates were normalized, and there was a function to convert from pixels if you prefer working that way.

[Calx]

Maybe it would be best if texture coordinates were normalized, and there was a function to convert from pixels if you prefer working that way.

That'd be ideal. I'm generating textures procedurally with different parameters per resolution/density so i'm in exactly the situation you've described.