SFML Complete Game Tutorial

[StormWingDelta]

Still can't find it.  I went through and compared your code to mine and I'm at a loss on this one.

http://
https://sites.google.com/site/sfmlworkscjr/sfmlfiles


The file labeled UnknownError has the code in it.  It should be easy to find errors like this one but I have no idea why I haven't spotted this one yet.

[Serapth]

Ahh, I think I've found your problem, I can't be certain because I am not running SFML2/CMake, so I can't test your project as posted.  That said, you have a definite no-no.


You have a #include "Game.h" in GameObjectManager.h, while having a #include "GameObjectManager.h" in Game.h, creating a circular dependency.

GameObjectManager.h should only include VisibleGameObject.h and nothing else.  Remove the #include "Game.h" from your GameObjectManager.h and the problem *might* go away.  


Generally what the error is saying is when it says "error C2146: syntax error : missing ';' before identifier '_something' " it generally means it doesn't know what somethings type is.

[StormWingDelta]

That's interesting and  :oops: .

I might have included it there for one reason or another because of something in one of the previous parts or there was something there that needed it at the time and I didn't move it to the other file.

It's where it should be now and not causing that loop anymore.

Funny how things can get forgotten with this much code and too bad the compiler isn't setup to mention these types of things rather then sending people on a wild goose chase for something that isn't the cause of the problem.



Thanks for the help.  The pong game on my end is up and running again.  I'm  going to go see if I can get Box2d into this to see what breaks this time.

The other things on that site were from other issues I was having that haven't been solved yet.  I'll start taking things off there that have been solved so people don't get confused.

[eot]

Some short feedback:
There are a few instances where the names of the function arguments in the declarations don't match with the names in the function implementation. Specifically arguments of type sf::RenderWindow (off the top of my head you used 'rdw' 'window' 'renderWindow'). I know the compiler doesn't mind, but I think it's better to keep the names the same, especially in a tutorial.

Also, even though it gets long I think you should mention every change to every file you make in each part. Personally I re-write all the code instead of copy-pasting it and it gets harder to follow along when there are required changes that aren't mentioned. Take a look at how lazyfoo did his SDL tutorials.

Overall I think it's very good though   so thanks a lot.
Just needs a little bit of polish.

[Serapth]

Some short feedback:
There are a few instances where the names of the function arguments in the declarations don't match with the names in the function implementation. Specifically arguments of type sf::RenderWindow (off the top of my head you used 'rdw' 'window' 'renderWindow'). I know the compiler doesn't mind, but I think it's better to keep the names the same, especially in a tutorial.

I wasn't aware I was even doing that, I did just look and found an example in VisibleGameObject.h, in the header I did:

virtual void Draw(sf::RenderWindow & window);

while in the implementation I did:

void VisibleGameObject::Draw(sf::RenderWindow & renderWindow)


Which I certainly shouldn't have done.  That said, parameter names in the definition are completely superfluous, they are ignored by the compiler and aren't required. This would have been equally valid:

virtual void Draw(sf::RenderWindow &);


I just personally find it easier to comprehend, especially when dealing with less obvious types, such as SomeFunc(int,int,char,int);


Anyways, you are right, that was a mistake on my behalf, but that's the explanation why the compiler doesn't complain, it really doesn't care about method names until implementation.

Also, even though it gets long I think you should mention every change to every file you make in each part. Personally I re-write all the code instead of copy-pasting it and it gets harder to follow along when there are required changes that aren't mentioned. Take a look at how lazyfoo did his SDL tutorials.

My thought when starting out was people would download the source each time or if not the "Click here to download Blah.cpp" links, an assumption that was very very wrong.  I figure from looking at stats, maybe 5 - 10% of people download the project files for each chapter.  So yeah, I really should have put more emphasis on the changes.

One of the big problems is, I take a long time between chapters and frankly forget what I've changed, especially when its a small one liner in Game.cpp or likewise.   Not saying you aren't right, I'm explaining why I kept doing it wrong!   For future tutorials I am taking a much different route.  I need to find a good diff tool for VS.  One of the major downsides to Visual Studio Express ( which I've used for the tutorials ) is the lack of plugin support.

Overall I think it's very good though   so thanks a lot.
Just needs a little bit of polish.

You are welcome, hope it helped.

[krrice]

First I want to thank you for doing this tutorial there is no other like that I've been able to find.

I am using SFML 2 and everything has worked up until this point.I am on part 6 and I have had to do some minor changes to the code because you are using 1.6. The part i am stuck on is Game.cpp,you use sf::Input and 2.0 does not use it anymore now it is sf::Keyboard, sf::Mouse and I dont know how to change the code to make this work. If you or anyone else has any suggestions I would appreciate it.Here is the part of Game.cpp I am stuck on.

 

Code: [Select]



const sf::Input& Game::GetInput()
{
return _mainWindow.GetInput();
}


And this is PlayerPaddle.cpp / I know that in 2.0 its Keyboard and KeyPressed instead of key and IsKeyDown

Code: [Select]



void PlayerPaddle::Update(float elapsedTime)
{

if(Game::GetInput().IsKeyDown(sf::Key::Left))
{
this->_velocity-= 5.0f;
}
if(Game::GetInput().IsKeyDown(sf::Key::Right))
{
this->_velocity+= 5.0f;
}

if(Game::GetInput().IsKeyDown(sf::Key::Down))
{
this->_velocity= 0.0f;
}

if(_velocity > _maxVelocity)
this->_velocity = _maxVelocity;

if(_velocity < -_maxVelocity)
this->_velocity = -_maxVelocity;


sf::Vector2f pos = this->GetPosition();

if(pos.x  < GetSprite().GetSize().x/2
|| pos.x > (Game::SCREEN_WIDTH - GetSprite().GetSize().x/2))
{
_velocity = -_velocity; // Bounce by current velocity in opposite direction
}

GetSprite().Move(_velocity * elapsedTime, 0);
}


[krrice]

This is what I have changed but it still does not work.


Game.cpp

Code: [Select]



const sf::Keyboard& Game::GetInput()
{
return _mainWindow.GetInput();
}


PlayerPaddle.cpp

Code: [Select]


void PlayerPaddle::Update(float elapsedTime)
{
if(Game::GetInput().IsKeyPressed(sf::Keyboard::Right))
{
this->_velocity+= 5.0f;
}
if(Game::GetInput().IsKeyPressed (sf::Keyboard::Down))
{
this->_velocity= 0.0f;
}

if(_velocity > _maxVelocity)
this->_velocity = _maxVelocity;

if(_velocity < -_maxVelocity)
this->_velocity = -_maxVelocity;

sf::Vector2f pos =this->GetPosition();

if(pos.x <= GetSprite().GetSize().x/2
|| pos.x >= (Game::SCREEN_WIDTH - GetSprite().GetSize().x/2))
{
_velocity = -_velocity; // Bounce by current velocith in opposite direction
}

GetSprite().Move(_velocity * elapsedTime, 0);
}


I get a message in Game.cpp that sf::RenderWindow has no member GetInput[/code]

[Serapth]

I haven't ported to 2.0 yet but from my glances tonight, it looks like Keyboard has been added as a global static method, instead of accessed via GetInput() in the RenderWindow

So instead of using Game::GetInput() at all, now you do sf::Keyboard::IsKeyPressed().


So, you get rid of GetInput() completely from Game, and in the case of PlayerPaddle code like this:

 if(Game::GetInput().IsKeyPressed(sf::Keyboard::Right))


You do this:

 if(sf::KeyBoard::IsKeyPressed(sf::Keyboard::Right))

[krrice]

I haven't ported to 2.0 yet but from my glances tonight, it looks like Keyboard has been added as a global static method, instead of accessed via GetInput() in the RenderWindow

So instead of using Game::GetInput() at all, now you do sf::Keyboard::IsKeyPressed().


So, you get rid of GetInput() completely from Game, and in the case of PlayerPaddle code like this:

 if(Game::GetInput().IsKeyPressed(sf::Keyboard::Right))


You do this:

 if(sf::KeyBoard::IsKeyPressed(sf::Keyboard::Right))

Thanks Serapth, I commented out the GetInput() from Game.cpp
and changed PlayerPaddle.cpp to if(sf::KeyBoard::IsKeyPressed(sf::Keyboard::Right)).It compiles fine now but now I have lost my paddle and ball maybe something simple.

[StormWingDelta]

Just wondering when the next part is coming out since you mentioned soemthing to do with a nightmareish bug of some kind in the game loop.

Once that issue is worked out I'm planning on using the basic classes of this game for others when I figure out a few more things.

Aside from that it is good so far.    

[Jove]

Serapth, out of interest will you be providing a SFML2 compatible version to download at any point?

Regards.

[Serapth]

@StormWingDelta, The bug isn't really all that dire, no worries, its a pretty simple fix, you can easily use this code as the basis for a future product.  It was actually something stupid that slipped in early and I just didn't review that code again.  ( It's the event loop ).

@Jove, I am going to actually do a post about porting to SFML, probably soon.  I won't do it for each chapter, but it should be clear enough to go from there.  What I will probably do is update the Part 2 solution, then part 9/10, so you can go with 2.0 from near the beginning or the end.  Updating all the middle ones though, just too much work.

[Jove]

Thanks, I agree with what you say there.  I have converted it to the latest 2 snapshot, but it's acting a little crazy and I'm not sure why yet.

[Razzeeyy]

Serapth, Hi again.
I came back with couple of questions about collision (actually about response to collisions...)

So as far as you know I'm making the tank game...
The collision between tank and bullet was easy to made.
But the collision between tanks more complicated.

My Collision model is something like this:
1)Test Collisions in pairs through all objects
2) if collision happend, then execute Collide method of objects and pass references to the collided objects, one to another
3) objects decide on their own what to do on collision

This model is enough for bullets, but for collision between tanks.. em.. Should I pass the coordinates of obstacle or... something else?

I tried to make a 'simple' tank collision (just forcing the forward movement to act as backward on collision so we make step out of collision..) but I don't think this is an elegant solution.

[Serapth]

Serapth, Hi again.
I came back with couple of questions about collision (actually about response to collisions...)

So as far as you know I'm making the tank game...
The collision between tank and bullet was easy to made.
But the collision between tanks more complicated.

My Collision model is something like this:
1)Test Collisions in pairs through all objects
2) if collision happend, then execute Collide method of objects and pass references to the collided objects, one to another
3) objects decide on their own what to do on collision

This model is enough for bullets, but for collision between tanks.. em.. Should I pass the coordinates of obstacle or... something else?

I tried to make a 'simple' tank collision (just forcing the forward movement to act as backward on collision so we make step out of collision..) but I don't think this is an elegant solution.

Hi Razzeeyy,

Your solution seems reasonable.  You could implement this as another base class or interface ( ICollidable ) and do exactly what you discussed as another per frame action ( like Draw and Update now ), or within Update in GameObjectManager.

If you are passing in a reference to the object that collided with another object, why would you need to pass coordinates? You would already have access to them via the reference.