Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML Game Development by Example - 4th SFML book  (Read 140785 times)

0 Members and 2 Guests are viewing this topic.

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: SFML Game Development by Example - 4th SFML book
« Reply #15 on: January 03, 2016, 01:40:10 am »
(... and uses modern C++)

This is why I asked about the source code, because if you look at the cover (I know you shouldn't judge a book by it's cover) you will see the following line of code blended into the background...

sf::Texture* texture = new sf::Texture();
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

OrderNexus

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Re: SFML Game Development by Example - 4th SFML book
« Reply #16 on: January 03, 2016, 07:20:11 am »
(... and uses modern C++)

This is why I asked about the source code, because if you look at the cover (I know you shouldn't judge a book by it's cover) you will see the following line of code blended into the background...

sf::Texture* texture = new sf::Texture();
With the exception of smart pointers, all of the code used in this book is modern. I have made a decision quite early on during the writing stage to stick to raw pointers for educational purposes. If you're picking this book up, it's fair to assume that you have at least a decent knowledge of C++, hence you probably have used smart pointers or at the very least have heard of them. At least to me, it seemed that learning how to properly dispose of dynamically allocated objects was more beneficial than using a feature that does it for you, especially since so many newbies have problems with memory leaks. Instead of using smart pointers and swiping the problem under a rug, I attempted to tackle it in a way that seemed the most fit. I guess we'll just have to wait and see how it works out in the long run though. :)

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: SFML Game Development by Example - 4th SFML book
« Reply #17 on: January 03, 2016, 11:37:46 am »
With the exception of smart pointers, all of the code used in this book is modern. I have made a decision quite early on during the writing stage to stick to raw pointers for educational purposes. If you're picking this book up, it's fair to assume that you have at least a decent knowledge of C++, hence you probably have used smart pointers or at the very least have heard of them. At least to me, it seemed that learning how to properly dispose of dynamically allocated objects was more beneficial than using a feature that does it for you, especially since so many newbies have problems with memory leaks. Instead of using smart pointers and swiping the problem under a rug, I attempted to tackle it in a way that seemed the most fit. I guess we'll just have to wait and see how it works out in the long run though. :)
I would argue that the correct way to manage dynamically allocated memory is with RAII and smart pointers. Teaching manual memory management seems misguided to me - especially since it's incredibly hard to get right and code te ds to get pretty ugly with lots of try-catch blocks if you really want to handle all possible leaks and smart pointers solve the whole problem quite elegantly.
I'd have written that line from the book cover as
auto texture = std::make_unique<sf::Texture>();

OrderNexus

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Re: SFML Game Development by Example - 4th SFML book
« Reply #18 on: January 03, 2016, 06:15:14 pm »
With the exception of smart pointers, all of the code used in this book is modern. I have made a decision quite early on during the writing stage to stick to raw pointers for educational purposes. If you're picking this book up, it's fair to assume that you have at least a decent knowledge of C++, hence you probably have used smart pointers or at the very least have heard of them. At least to me, it seemed that learning how to properly dispose of dynamically allocated objects was more beneficial than using a feature that does it for you, especially since so many newbies have problems with memory leaks. Instead of using smart pointers and swiping the problem under a rug, I attempted to tackle it in a way that seemed the most fit. I guess we'll just have to wait and see how it works out in the long run though. :)
I would argue that the correct way to manage dynamically allocated memory is with RAII and smart pointers. Teaching manual memory management seems misguided to me - especially since it's incredibly hard to get right and code te ds to get pretty ugly with lots of try-catch blocks if you really want to handle all possible leaks and smart pointers solve the whole problem quite elegantly.
I'd have written that line from the book cover as
auto texture = std::make_unique<sf::Texture>();

I agree, it is a more elegant solution. Not sure I'm on the same page about teaching manual memory management being misguided though. It's a useful skill to have, hence a subject worthy of being taught, as you yourself said that it's hard to get right. At the end of the day, it came down to a simple choice: Do I want a more elegant yet educationally lacking solution for non-production code, or one that is unjustly so looked down upon by many C++ modernists, but with a purpose of teaching something. I chose the latter, obviously, with relatively little negatives to show for it. Performance wasn't impacted in any way, which should always be your number one concern. Whether it was the right choice for the book remains to be seen, so I guess we'll just have to let time do its thing. :) Besides, we shouldn't be judging usage of raw pointers too harshly. The source code of SFML itself has lines like this in it:
m_impl = new priv::ThreadImpl(this);
...
delete m_impl;
m_impl = NULL;

On a side note, it wouldn't really be a huge task for the reader to utilize smart pointers while reading this book, should they choose to do so. The rest of the code is fairly modern and uses C++11 standards. With that said, I think we should wrap up this discussion, since it's really just a matter of opinion at this point. :)
« Last Edit: January 03, 2016, 06:19:02 pm by OrderNexus »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML Game Development by Example - 4th SFML book
« Reply #19 on: January 03, 2016, 06:48:23 pm »
Quote
Besides, we shouldn't be judging usage of raw pointers too harshly. The source code of SFML itself has lines like this in it
Sadly, C++98 has no proper alternative to offer, so this code is necessary. But all this crap will vanish once SFML (3) finally moves to C++11.
Laurent Gomila - SFML developer

hobby

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: SFML Game Development by Example - 4th SFML book
« Reply #20 on: January 03, 2016, 09:27:41 pm »
I'd have written that line from the book cover as
auto texture = std::make_unique<sf::Texture>();
I prefer to not start a religious war here, but since the previous discussion was on smart vs. raw pointers I'll allow myself to question the merit of auto in this example.
Usually over the course of a project, a line of code is read many more times than it is written. Surely if several people are involved in the project. Do you find auto better than the explicit std::unique_ptr<sf::Texture>?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10390
    • View Profile
    • development blog
    • Email
Re: SFML Game Development by Example - 4th SFML book
« Reply #21 on: January 03, 2016, 09:52:35 pm »
Usually over the course of a project, a line of code is read many more times than it is written. Surely if several people are involved in the project. Do you find auto better than the explicit std::unique_ptr<sf::Texture>?
It's quite redundant since the factory (i.e. std::make_unique<sf::Texture>) already indicates the type. Having it written out twice, could be interpreted as a bit of noise.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://dev.my-gate.net/

Elias Daler

  • Hero Member
  • *****
  • Posts: 603
    • View Profile
    • Blog
    • Email
Re: SFML Game Development by Example - 4th SFML book
« Reply #22 on: January 03, 2016, 10:26:25 pm »
Usually over the course of a project, a line of code is read many more times than it is written. Surely if several people are involved in the project. Do you find auto better than the explicit std::unique_ptr<sf::Texture>?
It's quite redundant since the factory (i.e. std::make_unique<sf::Texture>) already indicates the type. Having it written out twice, could be interpreted as a bit of noise.
Agreed. And auto makes it easier to refactor this code later. Suppose you want to change unique_ptr to shared_ptr. You'd need to change it twice (instead of only once) if you've written it this way:
std::unique_ptr<sf::Texture> texture = std::make_unique<sf::Texture>();

Or, suppose, you decide to change sf::Texture to another class, again, you'd have to change the same thing twice, which is a bad sign because some day you'll forget to change it somewhere which will lead (at best) to compilation errors and to hard-to-spot bugs at worst.
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

hobby

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: SFML Game Development by Example - 4th SFML book
« Reply #23 on: January 03, 2016, 10:58:01 pm »
It's quite redundant since the factory (i.e. std::make_unique<sf::Texture>) already indicates the type. Having it written out twice, could be interpreted as a bit of noise.
I tend to agree, in my view this example lies on the border (I had to start the discussion with something...) Have you seen auto i = 0; used in practice (I have)?

Agreed. And auto makes it easier to refactor this code later. Suppose you want to change unique_ptr to shared_ptr. You'd need to change it twice (instead of only once) if you've written it this way:
std::unique_ptr<sf::Texture> texture = std::make_unique<sf::Texture>();

Or, suppose, you decide to change sf::Texture to another class, again, you'd have to change the same thing twice, which is a bad sign because some day you'll forget to change it somewhere which will lead (at best) to compilation errors and to hard-to-spot bugs at worst.
Dynamically-typed languages excel at minimizing the code changes required for refactoring, and SFML has bindings in some of them. Still, I wouldn't go on to claim that they enable easier refactoring - the number of keystrokes is not the only metrics. I think the same holds for considering to which extent to adopt auto in C++.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10390
    • View Profile
    • development blog
    • Email
Re: SFML Game Development by Example - 4th SFML book
« Reply #24 on: January 03, 2016, 11:50:41 pm »
I tend to agree, in my view this example lies on the border (I had to start the discussion with something...) Have you seen auto i = 0; used in practice (I have)?
I don't think, this is the place for a general discussion about auto, especially if it's just for discussion's sake.
If you're really unsure, which to me doesn't seem like it, then you can read all the existing discussions on the web by various people some better known than others.

Let's not further hijack this thread.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://dev.my-gate.net/

Sanction

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: SFML Game Development by Example - 4th SFML book
« Reply #25 on: January 05, 2016, 12:41:37 am »
I just got the book today, skimmed threw it at work. Lots of content and some advance game programming techniques looking forward to going back and following it threw and studding the content.

I didn't like how the code was smushed together, being still a novice I like to see the pattern more clearly, but like I said there was lots of content and you can easily open up an example and see it more clearly.

I really liked how it walked you threw the system / pattern and keep adding to it. So like for the ECS you get a more clear understanding of how the ESC works and later shows you adding more components and systems adding even more.

Overall I'm really excited and I'll be sure to post more :D
Knowledge comes, but wisdom lingers. It may not be difficult to store up in the mind a vast quantity of facts within a comparatively short time, but the ability to form judgments requires the severe discipline of hard work and the tempering heat of experience and maturity.

OrderNexus

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Re: SFML Game Development by Example - 4th SFML book
« Reply #26 on: January 05, 2016, 03:37:17 pm »
I just got the book today, skimmed threw it at work. Lots of content and some advance game programming techniques looking forward to going back and following it threw and studding the content.

I didn't like how the code was smushed together, being still a novice I like to see the pattern more clearly, but like I said there was lots of content and you can easily open up an example and see it more clearly.

I really liked how it walked you threw the system / pattern and keep adding to it. So like for the ECS you get a more clear understanding of how the ESC works and later shows you adding more components and systems adding even more.

Overall I'm really excited and I'll be sure to post more :D
Thanks for showing your support! I hope you enjoy the rest of the book. :)

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10390
    • View Profile
    • development blog
    • Email
Re: SFML Game Development by Example - 4th SFML book
« Reply #27 on: January 06, 2016, 11:34:05 am »
Who could say no to a 5 bucks eBook. ;)

I very quickly went a bit over the source code and it looks quite good, even though I don't agree with some of the design decisions.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://dev.my-gate.net/

OrderNexus

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Re: SFML Game Development by Example - 4th SFML book
« Reply #28 on: January 06, 2016, 06:36:31 pm »
Who could say no to a 5 bucks eBook. ;)

I very quickly went a bit over the source code and it looks quite good, even though I don't agree with some of the design decisions.
I'm glad to hear it's acceptable. Regarding the design choices, I can already imagine what those would be for the most part. :) I hope that doesn't ruin the book for you, and you find something useful in it still. Thanks so much for purchasing it!

AncientGrief

  • Newbie
  • *
  • Posts: 32
    • Yahoo Instant Messenger - what?
    • View Profile
Re: SFML Game Development by Example - 4th SFML book
« Reply #29 on: January 11, 2016, 09:51:11 pm »
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)
« Last Edit: January 11, 2016, 10:52:51 pm by AncientGrief »
I grew up with C++...but then I met C#...got lazy...time to turn back to my one and only love!
My system:
Wintendo 10 with Intel i7 4770k
Palit GeForce GTX 980
16 GB RAM

 

anything