SFML Game Development by Example - 4th SFML book

[OrderNexus]

Hey,

I bought your book a couple of days ago. Working on the Snake chapter atm. Nice to read I think using pointers etc. is okay ... I for myself try to avoid them and will exchange your pointers to smart pointers...but I have a question:

The Game class in chapter 2 -> Building the game class has the method

Window* GetWindow();
 

why using a pointer instead of this?:

const Window& GetWindow() const;
//EDIT: the const may be ignored, later on it will be stupid to make it return a const Window...
 

Btw.: I try to be more const correct than the book, but I don't see it as a flaw, since the code is much more readable while learning Nice work so far! I also prefer it over the first book so far!

Edit2:
What does the prefix l_ for function parameters stand for?! LValue?!

Snake::Render(sf::RenderWindow& l_window)

Hi! Thanks for purchasing and reading the book! I'm glad you like it so far.

For the GetWindow() method, you absolutely could use a reference. It actually makes more sense in most cases, unless nullptr is a valid return value, in which case using a pointer would be best. Regarding const correctness, you're absolutely right. That was actually my intention. Shoving everything into one publication just seemed like too much, not to mention it would cause formatting problems every once in a while.

The "l_" prefix stands for local, meaning the argument is local to the function/method. There are better alternatives to using Hungarian notation though, so take that with a grain of salt.

[eXpl0it3r]

For the GetWindow() method, you absolutely could use a reference. It actually makes more sense in most cases, assuming nullptr is a valid return value.

Not sure if you meant to say that differently, but nullptr is not a valid return value for a reference of a window.

[Hapax]

The "l_" prefix stands for local, meaning the argument is local to the function/method. There are better alternatives to using Hungarian notation though, so take that with a grain of salt.

Should a parameter know where it comes from?
Not sure which function/method it is local to. The one it's passed to or the one it's passed from?

[OrderNexus]

For the GetWindow() method, you absolutely could use a reference. It actually makes more sense in most cases, assuming nullptr is a valid return value.

Not sure if you meant to say that differently, but nullptr is not a valid return value for a reference of a window.

Yes, you're right. Sorry, I was replying in a rush. It's fixed now. I did mean that pointers should be used, provided nullptr being returned is a possibility.

The "l_" prefix stands for local, meaning the argument is local to the function/method. There are better alternatives to using Hungarian notation though, so take that with a grain of salt.

Should a parameter know where it comes from?
Not sure which function/method it is local to. The one it's passed to or the one it's passed from?

I agree, it's not widely used and debatably unnecessary. It can be useful if the method/function has a similarly named local variable inside the body somewhere. This, as well as most of the design choices in the book are entirely optional and up to the reader to leave in.

[eXpl0it3r]

He meant local as in local scope as in that function body. I personally rather go with prefixing member variables, that way I know that every none prefixed variable is a local one.

[Hapax]

Ah, I get it now. It's so you can tell which one is only available to that function when they are named similarly (I use the member prefix method that eXpl0it3r mentioned).
I think I would probably consider a parameter to be passed from the outside though so "local" for something external seems odd to me. Of course, technically, if it's passed by value, that actual copy is only local but still...

[Mario]

If the naming confuses you, don't use it. However, you could also just use a different naming scheme, e.g. prefixing params with "a" for "argument".

[SpeCter]

For member variables i use the prefix "m_".
For function parameter names I use "t_" .
For local variables I just use no prefix.

But honestly, the only thing I care about is that people are consistent with their naming scheme and stick to it for the whole project.

[AncientGrief]

Hi! Thanks for purchasing and reading the book! I'm glad you like it so far.

For the GetWindow() method, you absolutely could use a reference. It actually makes more sense in most cases, unless nullptr is a valid return value, in which case using a pointer would be best. Regarding const correctness, you're absolutely right. That was actually my intention. Shoving everything into one publication just seemed like too much, not to mention it would cause formatting problems every once in a while.

The "l_" prefix stands for local, meaning the argument is local to the function/method. There are better alternatives to using Hungarian notation though, so take that with a grain of salt.

Thanks for the clarification I'm done with the Chapter "EventManager" now and I really got some new inspirations from this one! Nice work! And btw.:

enum StateType{
    Intro = 1, Intro_MainMenu, MainMenu, Game, MainMenu_Game
    Paused, GameOver, MainMenu_GameOver, Credits, MainMenu_Credits
    ...
    // Crying in the corner.
};
 

I had to laugh Love it when a book is not to strictly serious!

Edit: converting the code using smart pointers is not so hard as I first though...but remember: std::move is your friend ... totally forgot about this at first and wondered what the hell is wrong x_X 

Edit2: I am always coding with -Wall compiler flag and encountered some warnings:
   - Some class/struct ctor member intializations are in the wrong order (not in the order of their declaration)
   - LoadBingings() in the EventManager class => int end = keyval.find(delimiter); => changed it to size_t

[Cenobite]

The e-book costs €43.54 while the print+ebook costs €44.99. That's strange. I would expect e-book to be significantly cheaper. This book has everything that I would like to learn (well, except a chapter about SFML android development). I am going to buy it, but it's not exactly cheap.

[Tank]

Cenobite: There might be a discount in a couple of days.

[eXpl0it3r]

(on the ebook that is, like the rest of the SFML ebooks by Packt)

[seyuup]

Loving the book so far, however, I've hit a snag.

I'm at the beginning of Chapter 7 and just finished testing the Tile/Mapping classes. The background texture loads, but when I hit the close button or click the "exit" button on the main menu, I receive an exception. I believe the error is occurring because the Game object's deconstructor is called when the window closes, causing my SharedContext object to lose scope.

Thus, other objects that depend on the SharedContext for releasing resources cause an error. Also, the ResourceManager's deconstructor is being called first, so it purges all of the resources before the map can do so itself.

I hope someone will be able to assist me!

[Sanction]

The e-book costs €43.54 while the print+ebook costs €44.99. That's strange. I would expect e-book to be significantly cheaper. This book has everything that I would like to learn (well, except a chapter about SFML android development). I am going to buy it, but it's not exactly cheap.

I got the eBook for $5.00

[OrderNexus]

Loving the book so far, however, I've hit a snag.

I'm at the beginning of Chapter 7 and just finished testing the Tile/Mapping classes. The background texture loads, but when I hit the close button or click the "exit" button on the main menu, I receive an exception. I believe the error is occurring because the Game object's deconstructor is called when the window closes, causing my SharedContext object to lose scope.

Thus, other objects that depend on the SharedContext for releasing resources cause an error. Also, the ResourceManager's deconstructor is being called first, so it purges all of the resources before the map can do so itself.

I hope someone will be able to assist me!

That's really odd. I just tested it myself, and it seems to be working fine. Please feel free to send me your code through either the PM function on these forums, or directly to my email address: order.nexus.dev@gmail.com. I would be happy to help you out!

Edit: One thing you should check is the order in which data members of the classes are declared. Since they're allocated on the stack, the destruction of these objects will follow in the reverse order of declaration. Make sure to consult the code that came with the book, and if that doesn't work, please feel free to contact me!

The e-book costs €43.54 while the print+ebook costs €44.99. That's strange. I would expect e-book to be significantly cheaper. This book has everything that I would like to learn (well, except a chapter about SFML android development). I am going to buy it, but it's not exactly cheap.

The e-book on packtpub.com is priced at €35.99, while the paperback version + e-book costs €44.99. I'm not sure where you saw that price for just the e-book alone, but it doesn't seem right.