Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dada

Pages: [1]
For what it's worth (and I'm aware that's close to zero for most of you as this is just opinions from a guy with 2 posts who doesn't even use SFML anymore):

Fitzy and Ixrec are right for the most part and where they are wrong is because they're not going far enough or conceding points in the face of weak arguments.

The ideal SFML user experience can be glimpsed by looking at the Linux installation instructions:
1. sudo apt-get install libsfml-dev
2. done

This is true no matter where the user sits on the noob-to-pro spectrum. While a pro has the *ability* to compile from source and deal with all kinds of issues, they still *prefer* to use a library in packaged form (when it's just a simple dependency on their project). There's many reasons for that, with security and stability sometimes more important than mere convenience (although for a library that isn't hugely popular and arguably targeted at beginners, convenience is the main factor).

This super easy user experience isn't widespread on Windows (yet? I think Nuget has a real shot at bringing this about). In that context, it's perfectly justifiable to say "get the source, install CMake, follow these steps carefully". However that doesn't make the advantages of proper packaging go away, and people who volunteer helpful packaging solutions shouldn't be dismissed as counterproductive.

Not to mention that providing a workaround for an actual issue in the latest official release cannot be a bad thing, surely?

The behavior is well defined, it just happens to be a little tricky and it tripped me up for a minute. That's why I posted about it.

As for onCreate being off-limits: I saw it in the docs and wanted to use it so... Y'all try and stop me  ;).

My problem is already solved but I thought I'd post it with the solution since I hadn't found anything on the topic when I did a search earlier.

I have a class derived from Window that overrides the onCreate function:

class MainWindow: public sf::Window

    virtual void onCreate();

My original implementation of MainWindow's constructor looked like this:

        sf::Window(sf::VideoMode(640, 480, 32), "SFML Window")

However my onCreate wasn't getting called. The reason is that virtual functions are not "in effect" until the instance is done initializing, which happens exactly at the opening { of the most derived constructor.

So the simple fix is this:

    create(sf::::VideoMode(640, 480, 32), "SFML Window");

The Window sub-object is initialized with its default constructor first. That finishes the initialization of the complete object. Only then is the create function called, which calls the intended version of onCreate.

Hope that helps someone!

Pages: [1]