SFML community forums
General => General discussions => Topic started by: Nexus on July 16, 2011, 01:05:57 pm
-
Since many SFML users have already asked this question and it might be useful for people who port projects from SFML 1.6 to Git revisions of SFML 2, I have created a list of API and functionality modifications. Feel free to complete it, I will edit this post. Note that SFML 2 is not finished yet, so the current API is still subject to change.
I only want to mention the most important and not obvious API-breaking changes to keep a good overview. Red are changes which may still compile with old code, but which introduce silent bugs and hence require special attention. Blue are pure additions.
General- CMake instead of specific compiler solutions and makefiles
- Use SFML_STATIC to indicate static linkage instead of SFML_DYNAMIC for dynamic linkage
- Changed naming convention for functions from PascalCase to camelCase
System package
- Added sf::Vector2u typedef for sf::Vector2<unsigned int>
- Added explicit conversion constructors from different vector types
- All times (sf::Clock, sf::sleep(), ...) are now measured with the sf::Time class instead of float seconds
- sf::Thread works now with function objects, no more inheritance
- Split sf::Unicode::Text to high-level sf::String and low-level sf::Utf
- Removed sf::Randomizer
- Low-level memory functions operate on void* instead of char*
Window package
- Added sf::InputStream for customized resource loading
- Added events JoystickConnected and JoystickDisconnected to track plug/unplug of joysticks
- Replaced sf::Input with 3 separate classes sf::Mouse, sf::Keyboard and sf::Joystick. They use global inputs, not window-specific ones.
- Renamed sf::Window::GetEvent() to pollEvent()
- Sizes are returned as vectors
Graphics package
- Added low-level graphics API with sf::VertexArray, sf::Vertex, sf::Transform
- Added sf::RenderTexture as another render target
- Added viewport and rotation to sf::View
- Split sf::Drawable functionality into sf::Drawable (stateless interface) and sf::Transformable (convenience base class for transformable entities)
- Renamed sf::String to sf::Text
- Renamed sf::PostFX to sf::Shader
- Dynamic adaption of sf::Font, no more fixed size and character set
- sf::Font requires the source (file, memory, ...) to remain valid throughout its lifetime
- sf::RenderWindow::setView() now copies the sf::View
- sf::Rect stores (left, top, width, height) instead of (left, top, right, bottom)
- Changed sign of angles (concerns sf::Transformable rotations)
- Split sf::Image into sf::Texture (OpenGL texture) and sf::Image (pure pixel container).
- Renamed sf::Drawable::GetCenter(), SetCenter() to sf::Transformable::getOrigin(), setOrigin()
- Made transformable interface to get size/bounds more uniform, now there are getLocalBounds() and getGlobalBounds()
Network package- Added more overloads for sf::Packet's operator<< and operator>>
- Renamed sf::SocketTCP, sf::SocketUDP to sf::TcpSocket, sf::UdpSocket and made them non-copyable
Audio package- Added ability to seek in sound streams and musics
- Fixed sf::Listener's target that was a relative direction instead of an absolute position
-
Thanks Nexus.
-
Good work there! Thank you! :)
-
On SFML 1.6 sf::Image::SetSmooth() was set to true by default, on SFML 2.0 is set to false, right?
Is it worth adding it to the list?
-
And there is a new SFML\OpenGL.hpp that needs to be included if somebody do OpenGL stuff. It wasn't there in 1.6.
-
Here is my private changelog. It should be almost complete :)
I should rather put it in an official tutorial for SFML 2.0 ("Porting from 1.6 to 2.0"). I'll try to find the time to do it soon.
SYSTEM
- OS-specific implementations (threads, mutexes) no longer appear in the public headers
- Added thread-local storage classes
- Changed the sf::Thread interface
- Improved string handling (added sf::String (high-level) and sf::Utf (low-level))
- Added string conversions between UTF and latin-1 (ISO-5589-1)
- Errors are now written to a SFML specific stream (sf::Err()) rather than std::cerr
- Removed the sf::Randomizer class
- sf::Mutex is now recursive on all platforms (was not on Linux and Mac OS X)
WINDOW
- Changed WindowSettings to ContextSettings, changed default values (24, 8, 0) -> (0, 0, 0)
- Added the context version to ContextSettings (to be able to create OpenGL 3.x context)
- OpenGL headers are no longer included by default in sfml-window, it is now in SFML/OpenGL.hpp
- Added Style::Default
- Improved synchronization between events and corresponding states in sf::Input
- Merged VideoMode::GetModesCount and VideoMode::GetMode into a single function
VideoMode::GetFullscreenModes
- Renamed Window::UseVerticalSync to EnableVerticalSync
- Added a blocking WaitEvent function in sf::Window
- Added Window::GetSystemHandle()
- Added sf::Window::SetTitle
- Added mouse position to the Event::MouseWheelMoved event
- Added support for OpenGL 3 (and above) contexts
- sf::Input -> sf::Joystick, sf::Keyboard, sf::Mouse (directly connected to the OS rather than to sf::Event)
- Removed sf::Window::SetCursorPosition (see sf::Mouse::SetPosition(Window))
GRAPHICS
- Added sf::RenderImage
- View --> slightly changed interface
- Added viewport to sf::View
- Added rotation to sf::View
- Improved rendering performances
- Removed RenderWindow::Capture (use Image::CopyScreen instead)
- Removed RenderTarget::PreserveOpenGLStates, replaced with SaveGLStates/RestoreGLStates
- Added Image::GetMaximumSize()
- Renamed Image::GetValidTextureSize to Image::GetValidSize
- Views are now handled by value (copied), not by reference
- Renamed Shape::GetNbPoints to Shape::GetPointsCount (consistent with other similar functions)
- Glyph : Rectangle --> Bounds, TexCoords --> SubRect
- Renamed Shape::Set/GetOutlineWidth to Set/GetOutlineThickness
- Renamed sf::PostFx to sf::Shader, and made it more flexible (can be applied to individual drawables)
- Inverted angles in drawable classes
- Images are not smooth anymore by default
- Renamed sf::String to sf::Text
- Added Image::UpdatePixels for fast pixel updates
- sf::Rect is now defined as [left, top, width, height]
- Added a parameter to Sprite::SetImage, to allow auto-adjustment of the subrect to the size of the new image
- Fixed tab character not properly rendered in sf::Text
- Renamed the Center property of drawables to Origin
- sf::Font now dynamically adapts to the rendered text, there's no more fixed size and character set
AUDIO
- Removed dependency to stb_vorbis
- Renamed SoundRecorder::CanCapture to SoundRecorder::IsAvailable
- Fixed sf::Listener's target that was a relative direction instead of an absolute position
- Added support for saving audio files as ogg/vorbis
- Added the ability to seek in sound streams and musics
NETWORK
- Reorganized the socket classes, however the features remain the same
- Minor modifications to sf::IpAddress
- Removed dependencies to system specific libraries in the public headers
- Made packet handling with UDP sockets more robust
- Added support for Unicode strings in sf::Packet
- Got rid of whatismyip.org as the default server for public IP retrieval
- Changed sf::Packet::operator bool() to something similar that avoids inappropriate implicit conversions
GENERAL
- Huge improvements to the API documentation, it is now much more detailed
- Changed const char* to const void* in LoadFromMemory functions
- The external libraries used by sfml-graphics are now linked instead of being integrated into the source code
- Removed the Qt and wxWidgets samples
- Switched to CMake, dropped individual support for compilers/IDEs
- New naming conventions for binaries (major version number appears in Windows DLLs -- not import libraries)
- SFML_DYNAMIC -> SFML_STATIC
- Added the SFML_VERSION_MAJOR and SFML_VERSION_MINOR macros
- Added support for 64-bits builds
- Changed all times in SFML to be Uint32 milliseconds instead of float seconds
-
Ah nice, yours is slightly more detailed :D
Maybe it is worthwhile to emphasize backwards-incompatible changes and those who still compile but have other semantics. That would make it easier for people who just want to port projects without caring about all the new features. What do you think? I can colorize the points if you want ;)
-
Well The time is one on that. Because I could compile rbSFML after it was changed from float to sf::Uint32 which kind of scared me.
-
Maybe it is worthwhile to emphasize backwards-incompatible changes and those who still compile but have other semantics. That would make it easier for people who just want to port projects without caring about all the new features. What do you think? I can colorize the points if you want
Like I said, I'll rather try to write the corresponding porting tutorial ;)
-
Why inverted angles of the sf::Drawable :?:
-
Like I said, I'll rather try to write the corresponding porting tutorial ;)
That's a good idea, then you can mainly focus on the API breakers. But a complete list of changes in addition is useful, too.
Why inverted angles of the sf::Drawable :?:
Because they were mathematically incorrect, see here (http://www.sfml-dev.org/forum/viewtopic.php?t=4467).
-
I can't find Socket::isValid anymore in 2.0.
Should I forget it ?
-
I can't find Socket::isValid anymore in 2.0
Should I forget it ?
Yes.
* this is useless for UDP sockets
* for TCP sockets, you want to check if the socket is connected with GetRemoteAddress()
-
sf::Input -> sf::Joystick, sf::Keyboard, sf::Mouse (directly connected to the OS rather than to sf::Event)
I thought I was using SFML 2.0, or are these simply not implemented in the build I am using?
-
I thought I was using SFML 2.0, or are these simply not implemented in the build I am using?
It was implemented two weeks ago.
-
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. :)
-
System package
- sf::Thread works now with function objects, no more inheritance
So no more of this?
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?
-
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.
-
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 :P
-
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.
-
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.
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.
-
...Excellent information...
Wow, I'm an idiot. I understand now. I learned threads from Java, and it was a few years ago.
Thanks
-
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.
-
great job sfml team!
do you know where the version will be avaliable?
for linux and mac too?
-
Should note the very recent splitting of sf::Image in sf::Texture and sf::Image 8)
-
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.
-
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 ;)
-
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?
-
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.
-
Please do, it is very useful for people in the mean time :)
-
Where is sf::RenderImage?
Just downloaded a project that uses it, but the 2.0 snapshot doesn't mention it anywhere... then i read in this thread that sf::RenderImage was a new addition but i can't find it anywhere in the snapshot or the docs, now i got no clue how to compile the project..
Also, is it possible to download win32 DLLs from recent 2.0 snapshots anywhere?
And... do you have any idea when v2.0 might become official?
-
Where is sf::RenderImage?
It was renamed to sf::RenderTexture.
Also, is it possible to download win32 DLLs from recent 2.0 snapshots anywhere
No. But compiling it is really easy if you follow the detailed tutorial.
And... do you have any idea when v2.0 might become official?
No, sorry.
-
Hi,
I have just saw the topic about the graphical API refactoring. Does it mean it's a bad idea to use unstable SFML 2.0 today because a lot of thing will change soon ?
-
No, because the current classes will not change so much. Only sf::Shape will be significantly modified.
-
Time passes so fast...
I have updated the list with some important points. It's still largely incomplete, even if we focus only on the crucial API parts. Don't hesitate to post suggestions here :)