SFML Game Development -- A book on SFML

[Flash]

The publisher has a $5 E-Book Bonanza, so right now it's only 5$ at http://www.packtpub.com/
Thought people might be interested.

[thePhilosopher8]

I'm in the middle of reading the book and I decided to look at the source code to try to get a better understanding of they are teaching. However, I'm having trouble understanding the FOREACH statement

// Preprocessor trick to allow nested loops
#define BOOK_PP_CAT_IMPL(a, b) a ## b
#define BOOK_PP_CAT(a, b) BOOK_PP_CAT_IMPL(a, b)
#define BOOK_ID(identifier) BOOK_PP_CAT(auroraDetail_, identifier)
#define BOOK_LINE_ID(identifier) BOOK_PP_CAT(BOOK_ID(identifier), __LINE__)


// Macro to emulate C++11 range-based for loop
// Instead of for (decl : range) you write FOREACH(decl, range) as in the following example
//
// std::vector<int> v = ...;
// FOREACH(int& i, v)
// {
//     i += 2;
// }
#define FOREACH(declaration, container)                                                                                                                                                                                                                 \
        if (bool BOOK_LINE_ID(broken) = false) {} else                                                                                                                                                                                          \
        for (auto BOOK_LINE_ID(itr) = (container).begin(); BOOK_LINE_ID(itr) != (container).end() && !BOOK_LINE_ID(broken); ++BOOK_LINE_ID(itr))        \
        if (bool BOOK_LINE_ID(passed) = false) {} else                                                                                                                                                                                          \
        if (BOOK_LINE_ID(broken) = true, false) {} else                                                                                                                                                                                         \
        for (declaration = *BOOK_LINE_ID(itr); !BOOK_LINE_ID(passed); BOOK_LINE_ID(passed) = true, BOOK_LINE_ID(broken) = false)

I understand what it is being used for and how it is implemented, but I can't get how it actually works. I'm hoping somebody could help me out, that would be appreciated.

[eXpl0it3r]

You do not need to know how the FOREACH macro works. The only reason it exists, is because VS 2010 doesn't support range based for loops.
Consider the FOREACH macro a language feature. I don't think you've gone through all the code of SFML or the STL to understand how it works, they provide APIs and how it's implemented doesn't matter for you.

[starkhorn]

Hi,

This book looks great. A quick question, is the source code available for download for both the ebook and print versions?

[zsbzsb]

Hi,

This book looks great. A quick question, is the source code available for download for both the ebook and print versions?

Well this has been answered multiple times in this and other threads.... But the code is available on GitHub here.

[kalimatas]

Hi everyone!

I've just finished reading the 3rd chapter and got a problem - my ships are always positioned in the left top corner of the view, and, moreover, I can see them only after the view is scrolled up completely to its top border (better see on the screenshot).

http://yadi.sk/d/XjD72sGBF8UVZ

I rechecked my code several times - everything is like in the book. I would appreciate any help.

I'm using SFML 2.1 on Mac OS X 10.9.

Thanks.

[Nexus]

I rechecked my code several times - everything is like in the book. I would appreciate any help.

What does "like" mean, did you write the code yourself? It looks as if the airplanes have position (0,0).

Can you download the code from GitHub and compile it 1:1, without applying any changes?

[kalimatas]

What does "like" mean, did you write the code yourself? It looks as if the airplanes have position (0,0).

Can you download the code from GitHub and compile it 1:1, without applying any changes?

I do not know why, but I haven't tried to compile original source from Github. Now as I did compile it and it worked fine, it turned out to be a problem in my code and I was able to find it.

The problem was in Aircraft::drawCurrent method. My method looked like this:

void Aircraft::drawCurrent(sf::RenderTarget& target, sf::RenderStates states) const {
        target.draw(mSprite);
}
 

I forgot to pass states as the second parameter to braw. It should be:

void Aircraft::drawCurrent(sf::RenderTarget& target, sf::RenderStates states) const {
        target.draw(mSprite, states);
}
 

Thanks for helping!

[Roter_Fuchs]

Hey everyone,

the book really gives insight into some nice concepts. But I have a question concerning the ResourceHolder class template.

template <typename Resource, typename Identifier>
Resource& ResourceHolder<Resource, Identifier>::get(Identifier id)
{
        auto found = mResourceMap.find(id);
        assert(found != mResourceMap.end());

        return *found->second;
}

Why is the only error checking that's being done here an assert? Once we go into release and turn debug mode off, the found iterator may as well point to one-past-the-end. Shouldn't we always make sure that it is not .end() before using it?

[Nexus]

Have you read Chapter 2 until the end? The rationale behind this is explained in a detailed manner: Accessing a resource that hasn't been loaded is a logic error, i.e. a bug (that can be tracked down in Debug mode). You can't meaningfully react to such bugs at runtime, because they should never have occured in the first place.

[Roter_Fuchs]

Yes I did and I can understand your reasoning. But you justify the design choice with an assumption: The logic error will (or should be) tracked down in debug mode. In reality though (especially with large projects) you can not and will not track down all such bugs prior to release. So in the end users might be confronted with crashing software instead of just default or missing resources.

[Nexus]

Following your argument, assertions would be generally pointless, since every bug can eventually occur in Release mode.

The problem with using exceptions is that you can't do anything meaningful at that time. As it's not a runtime but rather a logic error, you don't know what went wrong, and as a result, everything you do to react to it can make things even worse. From that time point, the application state is corrupt.

Keep also in mind that ResourceHolder::get() is not the place to say "missing resources" (since they must have been loaded in advance, by design); this check was performed earlier in load(), and covered with an exception.

[Roter_Fuchs]

Following your argument, assertions would be generally pointless, since every bug can eventually occur in Release mode.

If you use them as an error handling tool only, then yes. But I view assertions more of a tool designed to help the software engineer to track down bugs, rather than handling them.

The problem with using exceptions is that you can't do anything meaningful at that time. As it's not a runtime but rather a logic error, you don't know what went wrong, and as a result, everything you do to react to it can make things even worse. From that time point, the application state is corrupt.

Keep also in mind that ResourceHolder::get() is not the place to say "missing resources" (since they must have been loaded in advance, by design); this check was performed earlier in load(), and covered with an exception.

No, they must not have been loaded, they should have been loaded. Let's assume we're dealing with a large game. Let's also assume that for some reason a load call to a resource has never been made (thus an exception could never have been thrown). May it be because someone accidently deleted the load call or it was never there to begin with. It doesn't matter why. It only matters that it is missing.
Of course an assert can help in debug mode to track down that error, but only if that special part of the game is being tested. And keep in mind that it's a big game. So chances are that it might not be tested at all.

Naturally this a constructed case. But one that can actually happen. In this case the design choice can lead to a crash for the end user. And that is something you should avoid at all costs.

[Nexus]

If you use them as an error handling tool only, then yes. But I view assertions more of a tool designed to help the software engineer to track down bugs, rather than handling them.

That's exactly how I see it. You technically can't handle bugs with assertions, the latter exist only for debugging and to alert the developer early of mistakes.

No, they must not have been loaded, they should have been loaded. Let's assume we're dealing with a large game. Let's also assume that for some reason a load call to a resource has never been made (thus an exception could never have been thrown).

I completely understand your point of view, but where do you draw the border? Do you always call std::vector::at() instead of operator[] because the index might be wrong? Do you check all divisors for zero even if you're sure the situation can't allow this? If not, why not? Such bugs might as well survive the tests and lead to crashes. This applies to tons of situations. It's also a bit a philosophical question, for example in Java exceptions are everywhere (to the point where it becomes annoying).

[SeriousITGuy]

I just started the book and gone through the first three chapters. And I must say it is amazing. Even after over a year of hobbyist game development I learned much out of it. I'm really looking forward to the rest of the book. Amazing Work. Just wanted to say thanks for this work