SFML Game Development -- A book on SFML

[Nexus]

Yes, I'd also switch between a play and a chat mode, triggered by a certain key (Return?).

Are you sure you're not missing other important events like this? You should probably only filter key pressed/released events.

By the way, you can use code tags like this: [code=cpp] [/code]

[alambda]

I'd call myself an intermediate C++ developer (and completely new to game development), and as such feel like the book was specifically aimed at me. I most certainly learned a lot of useful patterns reading it, thank you. I have some questions, some which were already asked and answered in this thread (such as why use heap allocation in ResourceHolder), and would greatly appreciate any replies:

1. What are the most obvious optimizations one might do? In my project, there is no collision detection, but rather it is about entities moving randomly on a map. As it stands, I can draw of the order of 10000 animated entities before I take a frame rate hit. I don't plan on ever having this many entities on screen at once, but might have a comparable number in the in-game world. Do you suppose the lowered performance is due to the many draws and that optimizations related to drawing i.e. culling would be the way to go? Alternatively, might this be because of the SceneGraph traversals and the scattered form of the data, meaning that I would need to group the relevant data better for less cache misses? Obviously I could try to parallelize the code, too, which should result in speed improvements.

2. What is a sensible way to control Views? The book implementation only has a View in World and player input through CommandQueue does not, and cannot, affect this. Does it make sense to have Views in SceneNodes and how could I, say, draw a dynamical GUI with buttons for the player to click, or have the player input control the scrolling of the view of the World. I understand how to technically use views and have an ugly hack in place, but I am asking if someone might be able to think of some nice organization for the code.

I have other questions (mostly about code organization), but I think these will do for now. Finally, I should say that I did not read the book cover-to-cover, but skimmed some parts, so I apologize if some of these were already discussed therein.

[Nexus]

Do you suppose the lowered performance is due to the many draws and that optimizations related to drawing i.e. culling would be the way to go? Alternatively, might this be because of the SceneGraph traversals and the scattered form of the data, meaning that I would need to group the relevant data better for less cache misses?

That's difficult to tell without measurements... I recommend using a profiler and see exactly where the bottlenecks are.

In general, too many draw calls to the graphics card can be mitigated by combining entities (sf::VertexArray), and contiguous arrays that store data and can be iterated in one pass improve cache efficiency (there can still be pointers/indices to the elements from elsewhere). But don't make your life more complicated if you don't need it, premature optimization is evil

Obviously I could try to parallelize the code, too, which should result in speed improvements.

That's not obvious. In fact, I suggest to avoid multithreading unless you see a clear benefit (exploiting the full processing power) or a bare necessity (one thread blocks, other functionality must remain responsive). Multithreading brings a considerable amount of complexity to an application, which is not always worth bearing.

how could I, say, draw a dynamical GUI with buttons for the player to click, or have the player input control the scrolling of the view of the World

For the GUI, you could first draw the world's view as you know it from the book, and then switch to a default view (starting at the origin and using the window's size) where the GUI elements are drawn.

Otherwise, it depends a bit on what flexibility you need. Do you need picture-in-picture (e.g. a small part of the window drawing another scene) or minimaps? Split-screen? I would not handle the view inside a scene node, because the whole scene graph (i.e. the game's scene) is usually rendered at once, from one point of view.

[alambda]

Thank you for the reply and the useful suggestions (sf::VertexArray, should I ever need it).

For the GUI, you could first draw the world's view as you know it from the book, and then switch to a default view (starting at the origin and using the window's size) where the GUI elements are drawn.

Otherwise, it depends a bit on what flexibility you need. Do you need picture-in-picture (e.g. a small part of the window drawing another scene) or minimaps? Split-screen? I would not handle the view inside a scene node, because the whole scene graph (i.e. the game's scene) is usually rendered at once, from one point of view.

Right, switching between views is indeed what I had in mind, but I am unsure how to propagate the inputs to this elegantly. For example, suppose a rightclick ought to open a menu, or that in the airplane game, the user input could affect the scrolling speed of the world.

Currently, the user input flows through a CommandQueue, which only affects SceneNodes. I can, for example, build a separate queue for commands to view, but this doesn't strike me as good design. So, alternatively, I could have a pointer to a special SceneNode in World, like PlayerAircraft* mPlayer which, being a SceneNode, can read inputs through the CommandQueue.  I could then in the World::update do something like if(mPlayer->isMenuOpen()) openMenu();.

I suppose the latter is in line with the book's implementation, but it somehow seems a bit circular and I am not really liking the idea that the entity would need to know about views and store data about it (such as the bool isMenuOpen() function).

Am I making any sense or am I completely off tracks here?

[Nexus]

Are we talking about a heads-up display (HUD) that is overlaid while the game keeps running, or a separate menu? In the latter case, I'd use another state. The book treats this scenario with the example of a pause menu.

The former case could be a user interface to health, ammo, progress in the level, score, etc. Currently, the World class holds and moves the view; World::draw() applies it. If you have a additional UI to draw, you could reset the view after drawing the scene. About input: if you want to work with commands, the least intrusive method would probably be a scene node that catches specific commands to alter the view. This scene node itself does not change the view, but exposes the view's state that can be polled by the World class.

Keep in mind that it's just one way of doing things; as we mentioned in the beginning of the book, the framework we provide is meant as a starting point and not as the ultimate solution to every game. So, don't hesitate to experiment a bit. If you are already experienced in game development architecture, you can also have a look at entity-component-systems. Although they solve some problems nicely, they are rather complex. Designing them is not an easy task, and you tend to invest even more time into planning (and sometimes over-engineering)... It's all about trade-offs.

[Carlitox]

I'm using the structure of the book to make games, I already Programmed a Pacman.

I want to find nodes by "key" in scene_graph. I need it for scripting and program the quest system of an action rpg. My problem I think it's that I don't understand recursion, i'm not sure if I can return a node.

template<typename T>
T* findNode(std::string c_key)
{
        if (c_key == key)
        {
                return (static_cast<T*>(this));
        }

        for (auto &itr : children)
        {
                itr->findNode<T>(c_key);
        }

                       
}

Then I call the function and it fails, I get the error typical when acceding to a method of an object pointing to null:

scene_graph->findNode<Enemy>("dog01")->getHp();

The problem it's the returning node because inside the find function the search works and I can get info. I feel like I'm not returng the value in the correct way.

If I check the info inside the find function for each entity it tells the info correctly.

if (c_key == key)
{
 std::cout << "Info" << (static_cast<T*>(this))->getHp() << std::endl // Works for each enemy
return (static_cast<T*>(this));
}

                       

[Ixrec]

This is a good example of something you could probably catch on your own if you used a debugger and stepped through the code.

I would assume the problem is that in the non-base case...

itr->findNode<T>(c_key);

...you find the value, then immediately throw it away instead of returning it to the caller.  You probably want a "return" on that line.

[eXpl0it3r]

Your compiler should also raise a warning, since not all code-paths end up with returning anything.
You have to take warnings serious and if you didn't get a warning, you should up your warning levels.

[Carlitox]

I found the solution. Instead of returning the value in the recursive function I use an auxiliar node to store the value and returning it. If it's not found there is an assertion.

template <typename T>
T* getNode(std::string c_key)
{
        SceneNode *aux_node = nullptr;
        findNode(c_key, aux_node);
        assert(aux_node != nullptr);
        return static_cast<T*>(aux_node);
}

void SceneNode::findNode(std::string c_key, SceneNode *&aux)
{
    if (c_key == this->getKey()) aux = this;
        for (auto& itr : children) itr->findNode(c_key, aux);
}
 

Then I call the function:

scene_graph->getNode<Enemy>("Nosferatu")

   

[Kanefa]

I have been using the following methods from the book to check for collisions in my personal project.

void   checkSceneCollision(SceneNode &sceneGraph, std::set<Pair> &collisionPairs);
void   checkNodeCollision(SceneNode &node, std::set<Pair> &collisionPairs);
 

My scene graph is quite a bit larger than the scene graph used in the the book's game. However, in release my game still runs fine (200 fps), but in debug it has become nearly unresponsive ( < 1 fps). I can't use the debug mode currently. 

I could toggle the size of the scene graph for the debug and release versions, but before I do that I want to understand why this has become necessary in my simple game.

I was curious if you had any insight into this? Thanks!

[Jesper Juhl]

As you have discovered, the compilers optimizer has a huge impact on C++ performance.
If you are using a recent GCC as your compiler, then you can get a much better debug performance experience by using "-ggdb -Og" instead of "-ggdb -O0" when generating your debug builds. The "-Og" switch turns on all optimizations that don't inhibit debugging as opposed to "-O0" which turns off all optimizations.

[Kanefa]

Thanks Jesper. I am using Visual Studio. I am looking into disabling debug support for iterators, but I will need to recompile all the libraries I use.

Makes me wonder what all they have to do to get a triple A title to run in debug mode.

[Mario]

Makes me wonder what all they have to do to get a triple A title to run in debug mode.

Probably unit tests and split modules (i.e. only debug what you really have to).

And you can also attach a debugger just-in-time in case there's a crash happening. You don't have to let it run connected all the time. With higher editions of Visual Studio you also get a "variable history", so you can jump back in time before the crash happened and go step-by-step from there, etc.

[Jesper Juhl]

In some cases it can also be necessary to debug optimized code. Fairly painful but not impossible.

[Grundkurs]

one question about the codebase of the book is bugging me.
The SceneNode-Class is conceptually a base class for the most Entities in the Game. Thus many of its methods are virtual because its intended that other classes derive from it. So why isn't SceneNode's destructor set to virtual to ensure a complete deletion of the derived objects to prevent object slicing when its held by a SceneNode (smart)pointer?