Using SFML with math libraries? (GLM, Eigen...)

[Elias Daler]

I was wondering if someone here uses math lib along with SFML. I just find sf::Vector2f functionality lacking a lot of time when I need to compute something hard. I ended up writing a bunch of mathematical functions for them myself, but the number of them is increasing and I'm considering to use GLM for all the math stuff.

So, my question is: have anyone used it succesfully SFML and what were the steps with SFML's integration? Maybe I should add some implicit conversions from sf::Vector2f to glm::vec2 and vice versa? Or maybe I should always use doSomething(float x, float y) when calling SFML's API when possible?

What other things may I want to do?

[Laurent]

The function overloads that take separate components will vanish (probably in SFML 3), so I wouldn't use them too much.

Automatic conversions between the two types is what I'd probably do.

[Elias Daler]

Yeah, and frequently converting from glm::vec2 to sf::Vector2f shouldn't cause much overhead, right?

And I wonder if I should just start using glm stuff for everything or still use sf::Vector2f in some places?

[Laurent]

Yeah, and frequently converting from glm::vec2 to sf::Vector2f shouldn't cause much overhead, right?

I don't think you'll get to the point where these conversions noticeably slow down your application

And I wonder if I should just start using glm stuff for everything or still use sf::Vector2f in some places?

That's hard to say without being in this situation, but I think I'd try glm everywhere, and only convert when interfacing with SFML.

[Elias Daler]

Okay, thanks! I'll see how it will work out and will ask some questions if they arise in the process.

[korczurekk]

I have successfully built and used SFML with 'slightly' modified Vector2.hpp file:

#ifndef SFML_VECTOR2_HPP
#define SFML_VECTOR2_HPP
#include <glm/vec2.hpp>

namespace sf
{
        template<typename T>
        using Vector2 = glm::tvec2<T>;

        // Define the most common types
        typedef glm::tvec2<int>          Vector2i;
        typedef glm::tvec2<unsigned int> Vector2u;
        typedef glm::tvec2<float>        Vector2f;
} // namespace sf

#endif // SFML_VECTOR2_HPP

It is pretty small modification to SFML's code and let's you do all you want without additional conversions, especially implicit ones (which are… bad af?). I thought this may be way to go for you.

[Laurent]

It is pretty small modification to SFML's code

Pretty small but it is one anyway, which prevents your code from working with official (and all other) SFML builds.

[korczurekk]

It is pretty small modification to SFML's code

Pretty small but it is one anyway, which prevents your code from working with official (and all other) SFML builds.

True dat. After all it's just a suggestion, @OP can decide what's the best approach for him.

Btw if I was forced not to modify SFML code, I'd use some proxy class that would inherit from sf::Vector2<T>, but also could be converted to and set by glm::tvec2<T>.

template<class T>
class ProxyVec
: public sf::Vector2<T> {
public:
        using sf::Vector2<T>::Vector2;

        glm::tvec2<T> glm() {
                return {this->x, this->y};
        }
        ProxyVec& operator=(glm::tvec2<T> v) {
                this->x = v.x;
                this->y = v.y;

                return *this;
        }
};

[Nexus]

If conversions between GLM and SFML vectors appear throughout your entire code base, your problem lies somewhere else.

Most probably, you have not properly separated the game logics from your rendering/graphics module. SFML is there to visualize the contents on your screen, not to store your game objects' positions. It can of course be handy to use sf::Vector2 also in your game logic, if the class is already there, but it's definitely not a requirement.

With a clean separation, you would update your graphics according to the state of your game logic -- ideally one layer in your application would be responsible for the interfacing of both. In this layer, you can then apply arbitrary transforms (e.g. units (m) to pixels, GLM to SFML vectors, radians to degrees, etc.). This would not only solve the problem described in this thread, but also allows you to treat both more independently, and modify one without affecting the other.

Also, as a side note: if not the entire flexibility of GLM is needed, it may be enough to enhance SFML's vector with some vector algebra functionality. One example would be my library Thor.Vectors.