SFML Game Development -- A book on SFML

[eXpl0it3r]

I hope nobody is gonna sue me for quoting the book.

C++ is a very powerful, but also very complex programming language; even after years one never stops learning. We expect you to understand the basic language features (variables, data types, functions, classes, polymorphism, pointers, and templates), as well as the most important parts of the standard library (strings, streams, and the STL). If you feel unsure, we recommend reading a good C++ book, before or in parallel to this book, since SFML and our code sometimes uses advanced techniques. Game development is a difficult topic on its own; it is very frustrating if you additionally have to fight C++. Even if it takes some time to reasonably learn the programming language, it is a good investment, since it will save you days of tedious debugging.

[georger]

What is required knowledge of c++ to read this?

I know the basics of c++ like pointers reference but dont have an practical experience on it.

Is my knowledge enough?

I read the book. Based on my own experience, my candid answer to your question is: you need at least intermediate C++ to work through it. The book is not for beginning C++ programmers. So, um, your knowledge most likely isn't enough (mine wasn't, and I worked hard to catch up), and you'll feel lost.

If you don't have any practical experience, go and get it. Get a free IDE/compiler combo (e.g. VS Express Edition, Qt Creator), buy a good book and - I can't stress this enough - work through *ALL* exercises.

The book uses some C++11. The book briefly explains each new C++11 feature before using it, but (understandably so) not in depth; here are some C++11 references I found useful:

Ten C++11 Features Every C++ Developer Should Use
The Biggest Changes in C++11 (and Why You Should Care)
C++11 Tutorial: Let Your Compiler Detect the Types of Your Objects Automatically
C++11 Tutorial: Lambda Expressions — The Nuts and Bolts of Functional Programming
Using C++11’s Smart Pointers

Finally, the class and application design becomes increasingly sophisticated as you work through the chapters. I found it helpful to draw class diagrams to understand the relationships between classes.

[Hiura]

I can't stress this enough - work through *ALL* exercises.

+1

I've seen so many students struggling mostly because they skip the exercises and jump directly to something too big for them. What Georger just said is really important if you want to succeed. Don't rush, take your time and go step by step.

Graphic programming is not that easy despite how cool it looks like. 

[FloatPeasant]

I am a newbie when it comes to c++ just started 3days ago and in the same time started using SFML.
can it still be worth getting this book despite im a total newb:P?

[eXpl0it3r]

See the above comments. The book requires a good basis in C++.
In general you should also learn C++ with a good book, before using SFML.

[FloatPeasant]

See the above comments. The book required a good basis in C++.
In general you should also learn C++ with a good book, before using SFML.

c++ primer from the list in the link seems neat for a beginner book:)

[Kanefa]

I ran into a bug with the following function from utility.cpp.

void centerOrigin(sf::Text& text)
{
        sf::FloatRect bounds = text.getLocalBounds();
        text.setOrigin(std::floor(bounds.width / 2.f), std::floor(bounds.height / 2.f));
}
 

The left and top coordinates for sf::Text are not guaranteed to be zero. Corrected code:

void centerOrigin(sf::Text& text)
{
        sf::FloatRect bounds = text.getLocalBounds();
        text.setOrigin(std::floor(bounds.left + bounds.width / 2.f), std::floor(bounds.top + bounds.height / 2.f));
}
 

[Nexus]

That's a good catch, thank you. I have to admit I'm a bit surprised that the local bounding rectangle doesn't start at the origin...

Out of interest, have you encountered this problem in a specific situation, where the text was wrongly positioned?

[Laurent]

I have to admit I'm a bit surprised that the local bounding rectangle doesn't start at the origin...

The bounding rect is calculated from the geometry, so it usually has a small offset on Y. This is a common question/issue on the forum

[Kanefa]

Out of interest, have you encountered this problem in a specific situation, where the text was wrongly positioned?

It is subtle, but I have been noticing it everywhere I use text. You can see it in the book's project. The text is a bit lower than it should be in the screenshot.

[zerrer]

The use of unique_ptr is a bad choice for SceneNodes, why are you using unique_ptr and then create other pointers using get() in your World class ? You should use shared_ptr if you want to share the memory.

[Rosme]

The use of unique_ptr is a bad choice for SceneNodes, why are you using unique_ptr and then create other pointers using get() in your World class ? You should use shared_ptr if you want to share the memory.

Not necessary. The fact it's using a unique_ptr indicates that the variable is owned by only one resource. It is acceptable to have a naked pointer coming from get() that connects to the unique_ptr instance. That means it is not the responsibility of whoever uses that pointer to delete it. He doesn't own it. The SceneNode is in fact owned by only one. So the use of unique_ptr is good.

[zerrer]

But the SceneNodes are not owned by one ressource, World class also owns SceneNodes who were intended to be owned by only one ressource.
The use of unique_ptr in this case is only complicating things, it would be much simpler and senseful with shared_ptrs.

[Nexus]

The use of unique_ptr is a bad choice for SceneNodes, why are you using unique_ptr and then create other pointers using get() in your World class ?

Because it describes the ownership semantics best. It doesn't matter whether there are additional pointers or references to the object stored in the unique_ptr, as long as its validity can be ensured. It's like having pointers or references to any other object.

But the SceneNodes are not owned by one ressource, World class also owns SceneNodes who were intended to be owned by only one ressource.

Not "also". The World class is the sole owner of the scene graph (that is, the root scene node). Every scene node owns its children. It's as simple as that.

The other references and pointers do not express an ownership relation, but a pure indirection. Ownership means being responsible of an object's lifetime. This is clearly not the case for the raw pointers that point to dedicated scene nodes, because the world is not supposed to destroy them through those pointers. The scene graph will take care of their destruction by itself.

The use of unique_ptr in this case is only complicating things, it would be much simpler and senseful with shared_ptrs.

The opposite is the case. shared_ptr looks easy to use, but it tends to make people think less about ownership semantics. Instead of having a clear owner, you distribute ownership over multiple instances in the hope that you needn't care about who cleans up. Don't use shared pointers as a GC replacement; it has been conceived for cases where you have shared ownership -- i.e. multiple instances that own one object and you cannot determine a single one which is responsible of it. Keep in mind that shared_ptr not only comes with some overhead, but it also enables memory leaks through cyclic references.

To understand our design choices better, I recommend reading this post.

[zombox]

I'm trying to implement text box to do a chat in multiplayer mode. How would you do it? I know about TextEntered event, but what is the best way to differentiate between normal key presses and text input?
This is how I would do it. Is it correct way to do that?

Code: [Select]

GameState::handleEvent(const sf::Event& event)
{
   if (!gui.isTextCapturing()) {
    FOREACH(auto& pair, mPlayers)
pair.second->handleEvent(event, commands);
   }
   gui.handleEvent(event);

}
and isTextCapturing is set by pressing some button.