Game States

[Chris231]

Hi,
i'm new to SFML (right now using 1.6), trying to write a Game State Manager for different states of my game (splash screen, menu, game, highscore..).
I found this tutorial, sadly it's using SDL. Is there a similiar Tutorial for SFML?

I tried to adopt the tutorial using SFML, but it didn't work out well.

Any help would be much appreciated, thanks!

[eXpl0it3r]

Welcome to the forum and SFML!

I can advice you to use SFML 2.0 since it's far more advanced and less buggy (last relevant commit to the SFML 1.6 was over two years ago...). The down side of SFML 2.0 is that at moment there aren't all tutorials available but it's not that hard to go with the 1.6 tutorials and 'translate' them with the help of the documentation.

As for your problem, I don't see how the tutorial you linked (btw the link is corrupt, don't know how you managed that ^^) is directly related to SDL. Sure if you download the source you get some SDL stuff, but the tutorial actually more emphazised on the state manager. You can look at the exampels of SFML to understand what exactly is needed to work with SFML and then implement the functions on your own.

Then there's the tutorial section maintained by the users which has also a tutorial on a basic game engine with a description for states.

[Nexus]

The basic principle remains the same, only the implementation differs for different multimedia libraries. And you needn't adapt everything 1:1 from the tutorial, it should rather give you the fundamental idea of an abstract "surface" base class and derived classes which implement the single surfaces.

But be careful with this tutorial, it seems to use a questionable C++ style (Init() and Cleanup() instead of constructors and destructors, C prefix for classes, no virtual destructors). Even one more reason not to copy code

[Chris231]

Welcome to the forum and SFML!

Hi

I can advice you to use SFML 2.0 since it's far more advanced and less buggy (last relevant commit to the SFML 1.6 was over two years ago...). The down side of SFML 2.0 is that at moment there aren't all tutorials available but it's not that hard to go with the 1.6 tutorials and 'translate' them with the help of the documentation.

This game is just for learning so I thought I start with 1.6 cause there are all tutorials available. With my next project I will switch to 2.0.

As for your problem, I don't see how the tutorial you linked (btw the link is corrupt, don't know how you managed that ^^) is directly related to SDL. Sure if you download the source you get some SDL stuff, but the tutorial actually more emphazised on the state manager. You can look at the exampels of SFML to understand what exactly is needed to work with SFML and then implement the functions on your own.

Yeah of course it's still c++, but for a beginner like me, it's hard to rewrite the SDL stuff

Then there's the tutorial section maintained by the users which has also a tutorial on a basic game engine with a description for states.

I will check that out, thanks.

The basic principle remains the same, only the implementation differs for different multimedia libraries. And you needn't adapt everything 1:1 from the tutorial, it should rather give you the fundamental idea of an abstract "surface" base class and derived classes which implement the single surfaces.

But be careful with this tutorial, it seems to use a questionable C++ style (Init() and Cleanup() instead of constructors and destructors, C prefix for classes, no virtual destructors). Even one more reason not to copy code

Yeah, I would have rewritten it anyway (I guess).


For example I tried to rewrite:
gameengine.h

Code: [Select]

SDL_Surface* screen;
with

Code: [Select]

sf::RenderWindow *window;

gameengine.cpp

Code: [Select]

// create the screen surface
screen = SDL_SetVideoMode(width, height, bpp, flags);
with

Code: [Select]

screen.Create(sf::VideoMode(800, 600, bpp), "test");

Leads me to something like:

Expression must have a pointer-to-function.

I will read some more tutorials and try to get this running. Thanks anyway!

[Nexus]

This game is just for learning so I thought I start with 1.6 cause there are all tutorials available. With my next project I will switch to 2.0.

I don't recommend that. Many things have changed in version 2.0, so you have to re-learn a lot. Or even worse, some subtile bugs arise, because something suddenly has other semantics (like sf::Rect).

Leads me to something like:

Expression must have a pointer-to-function.

Yes, don't use pointers unless really necessary. Just sf::RenderWindow.

[eXpl0it3r]

Hey look: It's a rewrite of the other source code to C++ and SFML. (Yes the other code was more like C with classes than C++).
You now may probably be able to follow the tutorial and look at the code, although some parts like singletons have be refactored out, because they aren't really that usefull for states. Also the objects initzialition and 'clean up' runs now all in the constructor and destructor. But since everything works with RAII (and one should keep it that way) the destructors are actually pretty useless...

I'll create a tutorial in the wiki section on GitHub and try to reach the creator of the blog to get it added to the list.

I hope it does help you and others.

@Nexus: Feel free to comment on the code, specially the C++11 bits.

[attachment deleted by admin]

[Chris231]

Thanks a lot! 
I will go through the code later and check the difference to my "SFML-Port".

Edit: You are using SFML 2.0, right?

[eXpl0it3r]

Edit: You are using SFML 2.0, right?

Would never use something else.
Although since the SFML code is so thin it would be easy to change it.

Edit: Woops, just noticed that the code from the blog missuses a std::vector as stack. Changed that quickly. (See above).

Edit2: I've created a new repository on GitHub, so it would be easier to share the code and make adjustments to it: SmallGameEngine

[davejc]

@ex

Edit2: I've created a new repository on GitHub, so it would be easier to share the code and make adjustments to it: SmallGameEngine

Random question on your GitHub repo, perhaps this deserves a new post: do you not store your xcode project (or whatever you use) on the repo? I can see why you wouldn't, but I'm curious what you usually do for your projects

[eXpl0it3r]

I use CMake to generate project/make files, but since I develop on Windows, haven't really tested any other OS or IDE.