List of modifications from SFML 1.6 to 2.0

[Klaim]

Laurent, when the time comes, could you add a tag in the repository to mark the last changeset that have the current drawing API?

As said in another thread I'll work in August on a game that requires to heavily manipulate this API, but I still want to use SFML2.0.
It would be easier to know which version to use that is not a WIP implementation, so maybe a tag is an easy way to do make people use a fixed api?

Or maybe you'll work on it on another branch or clone repository? If it's the case, then ignore my request.

[hagel]

System package

• sf::Thread works now with function objects, no more inheritance

So no more of this?

Code: [Select]


class MyClass : public sf::Thread{
private :
    virtual void Run(){
        for (int i = 0; i < 10; ++i)
            std::cout << "I'm the thread number 2" << std::endl;
    }
};
myClass.Launch();

Oh man. That will mess up my code.
What will the alternatives be? For someone trying to program as object oriented as possible?

[Nexus]

What will the alternatives be?

Any callables (functors, functions, member functions). It is a good decision to use them since they are far more powerful while reducing boilerplate code. For the full flexibility, you might want to take a look at Boost.Function and Boost.Bind, their functionality is part of the coming C++ standard.

What probably shows best their power is the fact that you can nearly keep your code: Just remove the inheritance and initialize the sf::Thread object with a member function pointer to the non-virtual MyClass::Run().

For someone trying to program as object oriented as possible?

Code doesn't automatically become more object oriented the more classes it uses. Inheritance to extend functionality is the Java approach, C++ additionally provides many (often better) alternatives. There is no reason why a thread cannot be a global function.

[MorleyDev]

boost::thread is being implemented to in C++(0/1)x as std::thread. I prefer using boost::thread anyway since it gives me access to the rest of boost's thready goodness

[hagel]

For someone trying to program as object oriented as possible?

Code doesn't automatically become more object oriented the more classes it uses. Inheritance to extend functionality is the Java approach, C++ additionally provides many (often better) alternatives. There is no reason why a thread cannot be a global function.

Of couse more classes aren't always more OOP but in my case, the code was for a server thread. The class will exist.

After finding the 2.0 documentation and looking at the examples I found that all three of them use an instance of sf::Thread.
Before I had a server object in my game class. Now I need a server object and a thread object. I know, not a big deal, but still.

Also, why remove the functionality of inheritance? Because of clashing with the other new functionality?

I'll have to experiment a bit with this.

[Laurent]

Before I had a server object in my game class. Now I need a server object and a thread object. I know, not a big deal, but still.

Also, why remove the functionality of inheritance? Because of clashing with the other new functionality?

It seems like you don't fully understand the new way of using threads.
There's no removed functionality (only more flexibility), and your server can remain as it is, you just need to change 2 lines of code in its implementation.

Code: [Select]

class Server
{
public:

    Server() : myThread(&Server::Run, this)
    {
    }

private:

    void Run()
    {
        ...
    }

    sf::Thread myThread;
};

The old way of using threads, with inheritance, was only a special case of what the new implementation allows.

[hagel]

...Excellent information...

Wow, I'm an idiot. I understand now. I learned threads from Java, and it was a few years ago.
Thanks

[Nexus]

That's what I wanted to say with that statement

What probably shows best their power is the fact that you can nearly keep your code: Just remove the inheritance and initialize the sf::Thread object with a member function pointer to the non-virtual MyClass::Run().

Additionally, sf::Thread now offers many alternatives, such as functors (especially created with std::bind) or global functions. In the end, you have many more possibilities with the new approach. By the way, std::thread also works with callables.

[prchakal]

great job sfml team!

do you know where the version will be avaliable?

for linux and mac too?

[LightWolf]

Should note the very recent splitting of sf::Image in sf::Texture and sf::Image  

[OniLinkPlus]

great job sfml team!

do you know where the version will be avaliable?

for linux and mac too?

There's no "SFML Team," it's just Laurent.
It's available on the github repository, accessible from the mainsite. If you meant when, it's available now, for every platform.

[Nexus]

Should note the very recent splitting of sf::Image in sf::Texture and sf::Image

I don't know, does it make sense if I keep the list here up-to-date?

There's no "SFML Team," it's just Laurent.

Don't forget Hiura for the Mac port and the language binding developers. But Laurent is the one designing the library

[LightWolf]

Should note the very recent splitting of sf::Image in sf::Texture and sf::Image

I don't know, does it make sense if I keep the list here up-to-date?

Why not?

[Nexus]

Since Laurent has the better list and announced to write a complete tutorial

But if you like, I can still keep the list in the initial post up-to-date, referring only to the most important changes.

[Jasmine]

Please do, it is very useful for people in the mean time