SFML Game Development by Example - 4th SFML book

[OrderNexus]

Thanks a lot for buying it! Yes, one of the most common things people like to bring up about it is the fact that some snippets of code are left out. It's what I had to do during the final draft stage, due to page count limitations. It may not seem like much, but those lines really do start adding up. If I have a chance to fix it up, I will do so in the next edition, as you said. The code you brought up in Chapter 3 has already been addressed, by the way. On this very page, northLynx was posting about having the same issue. Keep in mind that if you ever notice missing code pieces from the book, that means they were most likely simple setter/getter methods/functions. You can always consult the code files that came with the book in order to see the complete version with everything intact. Also, I will be watching this thread constantly, so if you have any additional questions, feel free to either shoot me a PM, or simply post here. I will do my best to address your concerns.

Once again, thank you so much for reading, and I hope the rest of it goes smoothly! Keep in touch if you have any more questions.

[GameBear]

Thanks for the reply.

ah yes, i see it up there, and glad to see the solution was the same as mine:) (I'll be honest, i did only read the first 4 pages of the thread

About the snippets of code. well I do hope you get the chance to edit it in, or at least mention that setters/getters are left out, so that people will know that before hand... adding them will make the book more "beginner friendly" but then again, your target audience doe not seem to be the absolute beginner

one thing i was wondering.

in chapter 3, you have this piece of code:

void Snake::Extend() {
   if (m_snakeBody.empty()) { return; }
   SnakeSegment& tail_head = m_snakeBody[m_snakeBody.size() - 1];

   if (m_snakeBody.size() < 1) {
      SnakeSegment& tail_bone = m_snakeBody[m_snakeBody.size() - 2];
      if (tail_head.position.x == tail_bone.position.x) {
         if (tail_head.position.y == tail_bone.position.y) {
            m_snakeBody.push_back(SnakeSegment(tail_head.position.x, tail_head.position.y + 1));
         }
         else {
            m_snakeBody.push_back(SnakeSegment(tail_head.position.x, tail_head.position.y - 1));
         }
      }
      else if (tail_head.position.y == tail_bone.position.y) {
         if (tail_head.position.x > tail_bone.position.x) {
            m_snakeBody.push_back(SnakeSegment(tail_head.position.x + 1, tail_head.position.y));
         }
         else {
            m_snakeBody.push_back(SnakeSegment(tail_head.position.x - 1, tail_head.position.y));
         }
      }
   }
   else {
      if (m_dir == Direction::Up) {
         m_snakeBody.push_back(SnakeSegment(tail_head.position.x, tail_head.position.y + 1));
      }
      else if (m_dir == Direction::Down) {
         m_snakeBody.push_back(SnakeSegment(tail_head.position.x, tail_head.position.y - 1));
      }
      else if (m_dir == Direction::Left) {
         m_snakeBody.push_back(SnakeSegment(tail_head.position.x+1, tail_head.position.y));
      }
      else if (m_dir == Direction::Right) {
         m_snakeBody.push_back(SnakeSegment(tail_head.position.x-1, tail_head.position.y));
      }
   }
}

While its a nice little algorithm, and nice way of explaining how to find direction from two "objects" i do not see the point of it.

As the game is made i cant see there ever being a time where you are only 1 segment long (reset makes us 3 long) and since we move in tiles, i dont see why you place the new segment behind the last one.
I'd just do something like this:

void Snake::Extend() {
   int i = m_snakeBody.size();
   m_snakeBody.push_back(SnakeSegment(m_snakeBody[i ].x,m_snakeBody[i ].y));
}

This will place the new segment on top of the last one, allowing it to "pop out" whenever the snake moves next.

of course, the other way teaches us more, but seems a bit overkill for its functionality...

or am i lost here?

[OrderNexus]

You are absolutely correct. However, in order for your code to work, you need to make sure you subtract one from the size of the container:

void Snake::Extend(){
        if (m_snakeBody.empty()){ return; }

        size_t last = m_snakeBody.size() - 1;
        m_snakeBody.push_back(SnakeSegment(
                m_snakeBody[last].position.x, m_snakeBody[last].position.y));
}

It's still a good idea to leave the empty container check in.

The longer segment of the code was intended to more clearly illustrate how the pieces would get positioned in space. I think I was leaning towards taking that out at some point, but I decided to leave it in at the last minute, because I thought it made the positioning more clear. I guess, since you picked up on it, I was at least partially right.

[GameBear]

Ah yes, my suspicion was correct.
And while it is "unnecessary" in this regard, it is as you said a nice way to illustrate how to get a direction, I can see this used for multiple things, (fire back port weapons?)

and oh yea, i did not implement the code, but i see what you mean about the size-1, i always forget that i returns from 1+ and not 0+ as normal counting

any ways, still reading and glad to read it all

[OrderNexus]

Ah yes, my suspicion was correct.
And while it is "unnecessary" in this regard, it is as you said a nice way to illustrate how to get a direction, I can see this used for multiple things, (fire back port weapons?)

and oh yea, i did not implement the code, but i see what you mean about the size-1, i always forget that i returns from 1+ and not 0+ as normal counting

any ways, still reading and glad to read it all

It's an honest mistake. Happens to the best of us, trust me. *cough* Mars Climate Orbiter *cough*.
Either way, please let me know if you have any further concerns, and happy reading!

[BM]

I've slowly been going over the book and it's been a great help understanding the inner workings of a game. I'm on chapter 5 now at the state manager part, I'm stuck and I can't figure out what's wrong. When I write the constructor for the statemanager class (p100) :

StateManager::StateManager(SharedContext* l_shared)
 : m_shared(l_shared)
{
 RegisterState<State_Intro>(StateType::Intro);
 RegisterState<State_MainMenu>(StateType::MainMenu);
 RegisterState<State_Game>(StateType::Game);
 RegisterState<State_Paused>(StateType::Paused);
}

the compiler doesn't recognize the RegisterState method or any of the <State_***> arguments (which I'm not sure what they're supposed to be at this point, different state classes?). As in the book, I've implemented the RegisterState method in the StateManager header as follow :

template<class T>
void RegisterState(const StateType& type)
{
        m_stateFactory[type] = [this]() -> BaseState*
        {
                return new T(this);
        }
};

[OrderNexus]

You're right, they are different state classes. You could include them in the StateManager.h file, or even in the .cpp, since the class definition itself doesn't rely on them. The first state "Intro" will be covered on page 110, and will be followed by the rest. For now, you can simply comment those RegisterState<...>(...) lines out, but remember to add them back in once the states are created.

It's odd that the compiler doesn't recognize the RegisterState method itself. Make sure it's defined in the StateManager.h file, inside the class as a member function like so:

class StateManager{
public:
  ...
private:
  ...
  template<class T>
  void RegisterState(const StateType& l_type){
    m_stateFactory[l_type] = [this]() -> BaseState*
    {
      return new T(this);
    };
  }
  ...
};

If the problem still persists, please feel free to paste in the errors you're getting. Good luck!

[BM]

You're right, they are different state classes. You could include them in the StateManager.h file, or even in the .cpp, since the class definition itself doesn't rely on them. The first state "Intro" will be covered on page 110, and will be followed by the rest. For now, you can simply comment those RegisterState<...>(...) lines out, but remember to add them back in once the states are created.

If the problem still persists, please feel free to paste in the errors you're getting. Good luck!

I figured it out just as you answered. What threw me off is that on page 110, just before "creating the intro state" section, it says the code should compile to give a black screen. Since it didn't work, I thought that I'd try to get that black screen before continuing on. The good news is that I have another problem!

Still in the state manager, in the SwitchTo method this time. The very first line calls the SetCurrentState method from the event manager class. On p.104, it says the SetCurrentState method will be covered shortly but I can't seem to find it, even by searching the entire document with ctr+f and "SetCurrentState".

[OrderNexus]

Odd. It may have been taken out, because it's a simple one-liner:

void EventManager::SetCurrentState(StateType l_state){ m_currentState = l_state; }

Sorry about that. Hope this helps!

[BM]

Odd. It may have been taken out, because it's a simple one-liner:

void EventManager::SetCurrentState(StateType l_state){ m_currentState = l_state; }

Sorry about that. Hope this helps!

Ah yea, I was thinking it would be only one line like that.

I still have an error, hopefully the last one before I can get the fabled black screen. On p.109, in the constructor for the game class

Game::Game(): m_window("Chapter 5", sf::Vector2u(800, 600)), m_stateManager(&m_context)

The compiler tells me that m_context is undefined. If I look at the state manager header, there's no m_context member variable either. Is it a typo for

SharedContext* m_shared;

or is it something else?

[OrderNexus]

Yes, the data member should be:

SharedContext m_context;

It's really weird, because I checked my code submissions, and it's correct there. It must've been "flubbed" during the final stages of the editing process somehow. My apologies.

[BM]

Yes, the data member should be:

SharedContext m_context;

It's really weird, because I checked my code submissions, and it's correct there. It must've been "flubbed" during the final stages of the editing process somehow. My apologies.

No worry, it's still immensively helpful.

I've changed all the instances of m_shared to m_context but I still get the m_context is undefined in the game constructor. Do you have any idea as to what might be the problem here?

[OrderNexus]

Did you include it in the Game.h header?

#include "SharedContext.h"

[BM]

I don't have a SharedContext.h file. I've defined 

struct SharedContext
{
        SharedContext() : m_wind(nullptr), m_eventManager(nullptr) {}
        Window* m_wind;
        EventManager* m_eventManager;
};

in the BaseState header. Even if I include BaseState.h, the m_context variable stays undefined.

[OrderNexus]

Your definition of the SharedContext structure is fine. Move it to SharedContext.h file though. It will be used in many more places later on, and you don't want it sitting inside the BaseState header.

Aside from that, make sure that the SharedContext.h header file is included in the StateManager.h header as well. Try to compile it and paste the error it gives you if it doesn't work.