SFML Game Development -- A book on SFML

[Oldie]

I have just received my copy of the book. I am now hoping that reading through this will help me polish the first version of my first project.

Anyway, big thanks to the authors for making it real !

[pixeltasim]

Just purchased the book last week and am working my way though it. I am converting the code listed into C#, which is proving quite fun and I am learning a lot about game development techniques in general. Great book, would buy again!

Also registered an account just to say how good this book is,

[Oldie]

In chapter 2 (page 37) it is said:

We do not store the sf::Texture directly, but we wrap it into a std::unique_ptr.

This design choice is not well explained, in particular why having elements of the map as pointers to textures instead of plain textures better. Could anyone list pros and cons of both choices?

In my current project, I first started with (unique) pointers to textures, before switching to plain textures. It is of course more simple to handle, and so far I have found nothing bad this way.

[Nexus]

Unique pointers are more flexible and generic, because they don't require:

• Copy or move semantics
• Default constructor

The first point is a requirement for STL containers, the second for some of the operations. For sf::Texture, this is not a problem, but sf::Shader and sf::Music can't be copied (although the music is not used in ResourceHolder). C++11 emplacement would be a partial solution, but is not supported by our target compilers.

The disadvantage is an additional indirection and heap allocation, but in relation to the heavy resources this should be reasonable. If you don't need the flexibility, you can of course use plain objects.

[Kanefa]

I am having an issue compiling chapters 7-10.  I read through the thread and saw a few others were affected.  The solution Groogy provides at the bottom of page 6 does not work for me and I see no one else confirming the workaround for VC++11 users.

To be clear I receive the following errors when compiling chapters 7-10.

error C2100: illegal indirection

and

error C3849: function-style call on an expression of type 'const std::_Bind<_Forced,_Ret,_Fun,_V0_t,_V1_t,_V2_t,_V3_t,_V4_t,_V5_t,<unnamed-symbol>>' would lose const and/or volatile qualifiers for all 2 available operator overloads

I verify there are no additional changes in the repository on GitHub for "SFML-Game-Development-Book / 07_Gameplay / Source /".  I then make the one line change Groogy suggests in DataTables.cpp at the end of page 6.

data[Pickup::HealthRefill].action = [] (Aircraft& a) { a.repair(25); };

The error about indirection is gone, but I still receive the following error.

error C3849: function-style call on an expression of type 'const std::_Bind<_Forced,_Ret,_Fun,_V0_t,_V1_t,_V2_t,_V3_t,_V4_t,_V5_t,<unnamed-symbol>>' would lose const and/or volatile qualifiers for all 2 available operator overloads

[eXpl0it3r]

I am having an issue compiling chapters 7-10.  I read through the thread and saw a few others were affected.  The solution Groogy provides at the bottom of page 6 does not work for me and I see no one else confirming the workaround for VC++11 users.

I assume you're using VS 11 then, right?

For me everything built fine with VS 11, so I'm not sure where the problem originates from on your end. Is you VS version up-to-date?

[  1%] Built target 01_Intro
[  1%] Built target 02_Resources
[  5%] Built target 03_World
[ 10%] Built target 04_Input
[ 19%] Built target 05_States
[ 30%] Built target 06_Menus
[ 44%] Built target 07_Gameplay
[ 61%] Built target 08_Graphics
[ 79%] Built target 09_Audio
[100%] Built target 10_Network
Install the project...

[Nexus]

Try the code from GitHub, not the one on the PacktPub site.

[Kanefa]

I pulled down the SFML-Game-Development-Book repository and I was able to successfully build all the projects with VC++11.  Chapter 7 now runs successfully.

Chapters 8-10 load into the menus, but when I press the "play" button the game crashes.

I am about a quarter into the book and enjoying it.

[Nexus]

Chapters 8-10 load into the menus, but when I press the "play" button the game crashes.

You use the original code and have followed the ReadMe.txt step by step?

If so, can you debug to see where the game crashes, and why? Is there anybody else who can reproduce this issue?

[georger]

I think I found a mistake in p.61.

On p. 58/59, SceneNode has a private drawCurrent() member function.
Entity inherits from SceneNode. Entity cannot see SceneNode's drawCurrent(), which is private.
On p. 61, Aircraft inherits from Entity. Aircraft cannot see SceneNode's drawCurrent(), which is private.

Aircraft declares a public drawCurrent() member function. It doesn't override SceneNode's drawCurrent(), which isn't even visible; since a new definition is being provided, rather drawCurrent() is being redefined in Aircraft. Otherwise it would break the access control system, by allowing the programmer to inherit a private virtual function and make it public in a derived class.

The text says the member function is being overridden; I think the function is being redefined.

Of course, I might be wrong and someone more knowledgeable in C++ than I am could clarify this.

[Nexus]

It's right that Aircraft::drawCurrent() should be private, thanks for noticing. However, the access specifier has no influence on overriding or redefining, only the function signature does. And since the latter is equal in both classes, the function is overriden.

[georger]

It's right that Aircraft::drawCurrent() should be private, thanks for noticing. However, the access specifier has no influence on overriding or redefining, only the function signature does. And since the latter is equal in both classes, the function is overriden.

Hmm. So you mean that, even though Aircraft::drawCurrent() is declared to be public, it's actually private? I looked left and right for a thorough explanation, but only came across this and this.

C++ has many dark corners, but I don't think this should be one of them. The compiler should just stamp its foot and refuse to compile such code. It's ambiguous and confusing.

[Nexus]

Hmm. So you mean that, even though Aircraft::drawCurrent() is declared to be public, it's actually private?

No, it's public. But it still overrides the private method SceneNode::drawCurrent(). Access specifiers and overriding are orthogonal concepts.

Mentioning the identifier Base::drawCurrent explicitly in derived classes is still not allowed, since it's private.

C++ has many dark corners, but I don't think this should be one of them. The compiler should just stamp its foot and refuse to compile such code. It's ambiguous and confusing.

A warning might indeed be appropriate if an access specifier is changed through inheritance, because this is mostly not intentional.

[georger]

Hmm. So you mean that, even though Aircraft::drawCurrent() is declared to be public, it's actually private?

No, it's public. But it still overrides the private method SceneNode::drawCurrent(). Access specifiers and overriding are orthogonal concepts.

Mentioning the identifier Base::drawCurrent explicitly in derived classes is still not allowed, since it's private.

C++ has many dark corners, but I don't think this should be one of them. The compiler should just stamp its foot and refuse to compile such code. It's ambiguous and confusing.

A warning might indeed be appropriate if an access specifier is changed through inheritance, because this is mostly not intentional.

Spot on. With any luck, it will trigger a warning in a future release of GCC.

Is this going to make it to the errata and/or GitHub?

[beefman]

Just bought the book and registered to say thanks! Just started working through the first chapter tonight and this is exactly the type of book I've been looking for. The language you use in it, and the way you explain things is a lot more approachable than other game dev books I've come across.

Writing my first game for a 3000 level C++ OOP class, and I couldn't have asked for a better reference