What pain points do you experience using SFML?

[eXpl0it3r]

Some of you may have already seen or even replied to, a week ago, we asked people on Twitter and Reddit what their pain points are or were when using SFML.

https://twitter.com/sfmldev/status/1078414172747169792
https://www.reddit.com/r/cpp/comments/aavn0s/what_pain_points_do_you_experience_using_sfml/

We started on Twitter and Reddit in hopes of catching those developers who aren't regularly visiting the forum, but since we're interested in collecting as much feedback as possible, we also want to ask everyone here.

What are/were the pain points you experience(d) while using SFML?

[FRex]

It's hard to think of anything major, but I don't want to leave this thread empty so I'll try.

1. Lack of certain helpers (e.g. for getting bottom and right of a rect, and left and top too to make it consistent, and maybe the four points of it too), minor vector functions like length, whatever, this is very subjective.

2. Lack of certain shortcuts, like getting coords (not pixel, but that too, honestly) from a mouse related event is kinda an insane construction considering how common it is.

3. Some 'closed' designs, like why can't I get vertices out of sf::Text to play with them in own code, SFGUI for a while used to poke at some private SFML bits by calculating memory offsets to members itself and casting pointers too. OTOH Window and Texture are mostly well behaved here with the 'native handles' but with some caveats at times, like how sf::Window hogs the userdata pointer of Windows window handle for itself (for the this ptr of sf::Window) so when you replace the wndproc you have nowhere to stuff your data to unless you subclass sf::Window and/or sf::RenderWindow yourself so that pointer there can be cast to your class. This came up in my example of how to use WinAPI for drag and drop with SFML: https://gist.github.com/FRex/3f7b8d1ad1289a2117553ff3702f04af

4. Holes in functionality and API, like no way to start maximized or hidden window, no way to save an image to a memory buffer, still no basic drag and drop support, etc.

I know the usual answer is DIY or 'bloat' or that we need the code and API to cover 3 major OSes first but that doesn't cover all of these things either (some are not OS specific or hard/awkward to DIY or so obvious there is no reason for not having them built in) and Windows is the platform many (most?) people care about when it comes to games (and SFML works well with WINE).

[Laurent]

I know the usual answer is DIY or 'bloat' or that we need the code and API to cover 3 major OSes first

If it was for answering that, we wouldn't bother posting this kind of questions

However I really wonder the final goal of that. The question is asked, but we don't know why. It's not like there was someone working on major evolutions of SFML.

[DeathRay2K]

Inefficiencies are the biggest pain point for me.

Dealing with textures is pretty painful when you don't want to deal in pixel coordinates. For example, converting normalized coordinates into pixel coordinates for every frame of animation, only to have that converted back into normalized coordinates for OpenGL is a big waste.

Having to write your own sprite manager in order to avoid separate draw calls for every sprite is a pain - especially when SFML presents a really inefficient way to handle sprites as the default, so new developers get used to that and have to relearn things with no help from SFML when they switch to batched sprites. I know batching should be implemented on a per-game basis ideally, but even basic batching would get users into the right habits from the start, and then they could inherit from the built in classes to customize the solution to suit their needs.

Built in text rendering is quite slow - I don't know why this is exactly, but it's a big bottleneck for UI rendering.
It's also not very useful for anything but the very simplest case. A rich text component or even just multiline component with text alignment would make a big difference here.

The network functions aren't great - no support for HTTPS is a deal-breaker for me, and even besides that it's quite finicky, so I had to switch to libcurl pretty quickly.

Having no resource manager feels like an oversight - again this would help people get into the right habits from the beginning. A virtual filesystem would also be super helpful here. Most projects that SFML is suited to would benefit from these, and they're pretty generic utilities.

Views are not easy to use or intuitive in the way they could be. It would be much more helpful to design these around the idea of a camera. Aspect ratio should not be as easy to screw up as it is now especially considering window resizing.

[FRex]

I wanted normalized coords too (and someone did in 2012). https://en.sfml-dev.org/forums/index.php?topic=17099

Text rendering slowness is interesting. I wonder if VertexBuffers would help there. You could even do that caching yourself in a few lines if SFML let you take out the vertices out of a Text after they were built.

Sprite batching and resource managers is kinda specific and there would be very opinionated choices. Camera too. I'm not even sure what you mean by Camera. Any specific framework that has a Camera as you'd like it?

PhysicsFS is a better virtual filesystem than SFML could ever be, there is no point in reinventing the wheel or wrapping it up in some 1:1 way that leaves out some 'too niche' functionality. Kinda same with libcurl. I don't even think of Network part of SFML, like ever. It's all Windows/Graphics + Audio to me.

In general if something is easy to do yourself, would have an opinionated design or there is already a superb library for it - I don't want it in SFML. Partly out of fear there would be weird choices I'd dislike.

[DeathRay2K]

I ended up handling text rendering slowness by rendering to textures for each text block. This works fine for static text, but doesn't help when the user is editing a large text block. Didn't try VertexBuffers there, but I imagine that still wouldn't help for the case where text might be changing.

The thing about sprite batching being opinionated is that implementing sprites in an unbatchable manner is opinionated design itself. It's not just batching ambivalent, it makes sprite batching counter to the design of the built in sprites. I think sprint batching could be done in a reasonably generic way that at least gives the user a starting point to customising a solution to their needs.

After refreshing my memory of SFML's views, by cameras I essentially mean better managing of the relationship between viewports and views. For most applications, games included, you really want an output that will have square pixels, and unless explicitly zoomed, you want 1:1 pixel sizes as well. Right now you have to actively manage a viewport and view to achieve that.

PhysicsFS and libcurl are both fine, but they're also both complex C libraries. They have C++ wrappers out there, but what I've seen are really very thin wrappers that don't make the libraries any easier to use, or require referencing documentation any less. Often using a C++ wrapper for a C library just means checking through two sets of documentation to find what you need instead of one. I would prefer having smaller scoped C++ solutions to networking and virtual file systems with an API that makes sense for a C++ codebase.

In these cases, I usually end up writing my own wrappers that include the functionality I need. And that's fine, but there are a whole bunch of those that I have to set up for every SFML project. So I think that qualifies as a pain point: it's one (or two, or ten) more thing(s) that need to be created, configured, or included before I can start using SFML productively.

[gws923]

It's also not very useful for anything but the very simplest case. A rich text component or even just multiline component with text alignment would make a big difference here.

This is by far my biggest gripe.  I find myself often having to do a lot of tinkering with sf::Text and wondering why I have to write my own functions for things like multi-line text centering.  When I asked about it a couple years ago I was told to do it myself.  Yeah, that's fine, I'm happy to do it, but it seems like there's a bit of functionality missing from sf::Text that is not just specific to my needs, but rather features that most users would want.  I can see why these features might be low priority, but they don't even seem to be on the roadmap anywhere.

[Sub]

It's also not very useful for anything but the very simplest case. A rich text component or even just multiline component with text alignment would make a big difference here.

This is by far my biggest gripe.  I find myself often having to do a lot of tinkering with sf::Text and wondering why I have to write my own functions for things like multi-line text centering.  When I asked about it a couple years ago I was told to do it myself.  Yeah, that's fine, I'm happy to do it, but it seems like there's a bit of functionality missing from sf::Text that is not just specific to my needs, but rather features that most users would want.  I can see why these features might be low priority, but they don't even seem to be on the roadmap anywhere.

I found myself implementing common text operations like multi-line text centering as well.  I wonder how much effort has been collectively wasted here.

[Elias Daler]

It's also not very useful for anything but the very simplest case. A rich text component or even just multiline component with text alignment would make a big difference here.

This is by far my biggest gripe.  I find myself often having to do a lot of tinkering with sf::Text and wondering why I have to write my own functions for things like multi-line text centering.  When I asked about it a couple years ago I was told to do it myself.  Yeah, that's fine, I'm happy to do it, but it seems like there's a bit of functionality missing from sf::Text that is not just specific to my needs, but rather features that most users would want.  I can see why these features might be low priority, but they don't even seem to be on the roadmap anywhere.

I found myself implementing common text operations like multi-line text centering as well.  I wonder how much effort has been collectively wasted here.

I wonder how much of it can be done without changing private API? Sounds more like external libraries problem to me. I really don't want SFML to become bloated with all kinds of stuff, but at the same time I think we need to endorse other SFML libraries and make them easy to find and use.

[unlight]

I might be a bit late to the party here. I would like to second FRex's gripe with the having no access to the vertices of SFML'S entities. Creating batch systems would be less painful if we could copy vertices from existing entities to render in more suitable ways when needed. I assume that hiding the internal state of these entities is to ensure that objects are only used as intended without ambiguity, but I feel like a getVertices function would go a long way.