Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML Game Development -- A book on SFML  (Read 259716 times)

0 Members and 1 Guest are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML Game Development -- A book on SFML
« Reply #270 on: March 30, 2015, 11:16:47 am »
The SceneNode destructor is virtual.

There's no need to declare it again because it is inherited from sf::Drawable.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Grundkurs

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #271 on: March 30, 2015, 12:31:19 pm »
oh now i see! That was the bit i was missing. Now everything makes sense again, thanks for the hint! :-)

psteiner

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #272 on: April 05, 2015, 02:11:16 am »
Hi, I'm working through the book, currently at Chapter 5. Up to this point in the book, the game FPS stats are implemented as members of the Application class. After working through the State and StateStack code, it occurred to me that I could make the stats into a "DebugState" object, essentially the same as the MenuState, so that display of the stats can be toggled on and off with the "D" key.

I'd also like to show the Player Aircraft's coordinates on the DebugState layer. However, after the code reorganization with the State objects, the Aircraft object is now a private member of the World object, which is in turn a member of the GameState object, and not so easy to access from another State object:

class GameState : public State
{
   ...
    private:
        World mWorld;
}

class World : public sf::NonCopyable
{
    public:
        explicit                            World(sf::RenderWindow& window);
    ...
    private:
       
        Aircraft* mPlayerAircraft; <-- need to get x,y from this member
};

class Aircraft : public Entity {...}

class Entity : public SceneNode {...}

class SceneNode
{
    public:
        sf::Vector2f getWorldPosition() const; <-- method to get x,y
}

 

Perhaps I could move the World member from GameState into Application, then add it to the State::Context? It would then be accessible to all States, in the same way as the Player object:

class Application
{
...
private:

    sf::RenderWindow        mWindow;
    TextureHolder           mTextures;
    FontHolder              mFonts;
    Player                  mPlayer;
    World                  mWorld;

    StateStack              mStateStack;
};

// Constructor
Application::Application()
    : mWindow(sf::VideoMode(640,480), "States", sf::Style::Close)
    , mTextures()
    , mFonts()
    , mPlayer()
    , mWorld(mWindow)
    , mStateStack(State::Context(mWindow, mTextures, mFonts, mPlayer, mWorld))
{
    ...
}
 

Any ideas or hints are welcome!

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML Game Development -- A book on SFML
« Reply #273 on: April 05, 2015, 10:39:08 pm »
Perhaps I could move the World member from GameState into Application, then add it to the State::Context?
That doesn't make sense from a semantic standpoint. A world exists only during the game, i.e. within the game state.

Don't just choose the seemingly simplest approach, it will make your whole design more complex if the lifetime of all the world and game objects is extended to the application duration. Furthermore, there's no reason why the application would need to access the world directly. Keep functionality as local as possible, and don't make interfaces bigger than necessary.

What you can do however is put another object in Context, which acts as a bridge between the two states. An example is a dedicated small class that offers a method to query the player's position. World would then initialize that object (or a pointer to it).
« Last Edit: April 05, 2015, 10:42:19 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

psteiner

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #274 on: April 07, 2015, 06:29:23 am »
Perhaps I could move the World member from GameState into Application, then add it to the State::Context?

What you can do however is put another object in Context, which acts as a bridge between the two states. An example is a dedicated small class that offers a method to query the player's position. World would then initialize that object (or a pointer to it).

Thanks for the suggestion. I later realized that what I'm trying to achieve almost fits an Observer or Mediator pattern:

http://sourcemaking.com/design_patterns/mediator:
Quote
...Mediator defines an object that controls how a set of objects interact..

The "small object" you suggest could be the Mediator between State objects.

http://sourcemaking.com/design_patterns/observer:
Quote
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.


Alternatively, the State class could inherit from an Observer interface, allowing State objects to publish and subscribe to whatever changes a state decides to publish.

In any case, you've pointed me in the right direction.

Thanks

SeriousITGuy

  • Full Member
  • ***
  • Posts: 123
  • Still learning...
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #275 on: April 07, 2015, 10:53:14 am »
One question to your approach of a "debug state": How can you calculate the correct fps when it is done via a state in the state stack? The state stack is updated with a fixed time step and therefore you cannot count the number of rendered frames? I wonder how the Application::updateStatistics - Member could be refactored into a member function of a debug state for that purpose?

alphan95

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #276 on: September 21, 2015, 04:25:41 am »
I am getting the following error message when I try to compile the tutorial code.

[  1%] Linking CXX executable 01_Intro.exe
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x11f): undefined reference to `FT_Set_Pixel_Sizes'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x2ce): undefined reference to `FT_Set_Pixel_Sizes'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x31a): undefined reference to `FT_MulFix'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x4ae): undefined reference to `FT_Set_Pixel_Sizes'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x4fa): undefined reference to `FT_MulFix'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x68a): undefined reference to `FT_Set_Pixel_Sizes'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x85a): undefined reference to `FT_Get_Char_Index'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x86b): undefined reference to `FT_Get_Char_Index'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x88a): undefined reference to `FT_Get_Kerning'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0xec6): undefined reference to `FT_Done_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0xeea): undefined reference to `FT_Done_FreeType'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0xfe5): undefined reference to `FT_Init_FreeType'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1017): undefined reference to `FT_New_Memory_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x102e): undefined reference to `FT_Select_Charmap'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1123): undefined reference to `FT_Done_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1144): undefined reference to `FT_Done_FreeType'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x11d4): undefined reference to `FT_Done_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x12d2): undefined reference to `FT_Init_FreeType'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x12fc): undefined reference to `FT_New_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1313): undefined reference to `FT_Select_Charmap'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1463): undefined reference to `FT_Done_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1484): undefined reference to `FT_Done_FreeType'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1543): undefined reference to `FT_Done_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1646): undefined reference to `FT_Init_FreeType'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1714): undefined reference to `FT_Open_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x172f): undefined reference to `FT_Select_Charmap'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1894): undefined reference to `FT_Done_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x18b5): undefined reference to `FT_Done_FreeType'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1964): undefined reference to `FT_Done_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1ac7): undefined reference to `FT_Done_Face'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1ae8): undefined reference to `FT_Done_FreeType'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1e98): undefined reference to `FT_Set_Pixel_Sizes'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1ec8): undefined reference to `FT_Load_Char'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1ee7): undefined reference to `FT_Get_Glyph'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1f2f): undefined reference to `FT_Glyph_To_Bitmap'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1f8d): undefined reference to `FT_Done_Glyph'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x1f92): undefined reference to `glFlush@0'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x20fb): undefined reference to `FT_Bitmap_Embolden'
C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj):Font.cpp:(.text+0x2134): undefined reference to `FT_Outline_Embolden'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:/SFML-2.3.2/lib/libsfml-graphics-s.a(Font.cpp.obj): bad reloc address 0x17 in section `.text.unlikely'
collect2.exe: error: ld returned 1 exit status
01_Intro\Source\CMakeFiles\01_Intro.dir\build.make:128: recipe for target '01_Intro/Source/01_Intro.exe' failed
mingw32-make[2]: *** [01_Intro/Source/01_Intro.exe] Error 1
CMakeFiles\Makefile2:84: recipe for target '01_Intro/Source/CMakeFiles/01_Intro.dir/all' failed
mingw32-make[1]: *** [01_Intro/Source/CMakeFiles/01_Intro.dir/all] Error 2
Makefile:126: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

Any help? I am u sing the most recent version of SFML.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10819
    • View Profile
    • development blog
    • Email
Re: SFML Game Development -- A book on SFML
« Reply #277 on: September 21, 2015, 08:53:07 am »
If you link SFML statically, you need to link against all of SFML's dependenceis, as stated in the official tutorial.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

alphan95

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #278 on: September 21, 2015, 07:13:30 pm »
Thanks. I'll do dynamic for now since that seems easier. Don't have to modify the cmake file.

OfenPower

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #279 on: November 01, 2015, 12:08:34 pm »
Hello, i have one little question:

Does this book work with SFML 2.3.2 too or do I need to use SFML 2.0?
I made bad experiences with Tutorial Books which were using older versions (some functions were out-of-date etc.).

Greetings
Ofen

PS: Sorry for writing mistakes, my english writing skills are not that good.


Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML Game Development -- A book on SFML
« Reply #280 on: November 01, 2015, 12:26:25 pm »
All SFML 2.x versions are backward compatible, so you can safely use the newest version. No breaking change is made: if stuff needs to be removed then it is marked as deprecated and kept until the next major version (SFML 3).
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML Game Development -- A book on SFML
« Reply #281 on: November 01, 2015, 12:36:07 pm »
No breaking change is made
This is true for the code, but not for the linking, which has changed in SFML 2.2.

I recently adapted the CMake scripts and introduced a case differentiation, so it should now work for all SFML 2 versions. If it doesn't, please report it, so we can fix potential bugs.

OfenPower, just make sure you use the code from the official repository, not Packt's website.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Oldie

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #282 on: April 16, 2016, 02:02:39 pm »
If I’m not mistaken, the class Button is the only class whose instances are actually packed into containers of class Container, which holds Components together. If you had to pack a set of Components other than Buttons (say Text boxes eg.) in another Container instance, how would you proceed? The problem is that this other class would need specific methods to work with (like reading input text), not needed by nor working with Buttons.
One solution would be to create sub-classes of Container, one for each type of widget, but it feels like adding way too many classes. Any other solution?
Working on a Tic-tac-toe game

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML Game Development -- A book on SFML
« Reply #283 on: April 16, 2016, 03:13:22 pm »
If you had to pack a set of Components other than Buttons (say Text boxes eg.) in another Container instance, how would you proceed?
Use Container::pack(), that's what it's for. I don't see a problem with more classes deriving from Component (not Container), if they represent different UI components.

This is the typical Composite Pattern, by the way.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Oldie

  • Newbie
  • *
  • Posts: 34
    • View Profile
Re: SFML Game Development -- A book on SFML
« Reply #284 on: April 17, 2016, 06:29:50 pm »
I don’t know if it’s a problem, but having classes like ButtonContainer and TextBoxContainer (and more) aside classes Button and TextBox (and more) seems like defeating the purpose of the original idea of a generic class Container. After all, the only need is to pack widgets of a same type and same functional group together, no more no less (and getting rid of lots of range-based for loops).
But it looks like I found my way with… lambdas. The lambda is given pointers to various widgets, and is stored inside one widget through std::function (like I had been doing so far with buttons executing code when clicked), before packing said widget into a container… a generic container. Now I don’t need to read some variable deep inside the component hierarchy and therefore I don’t need specific methods fulfilling this need; instead the std::function is executed when a certain event reaches and activates the widget.
Lambdas appear to be the foundation of my technical design, they blossom everywhere. :D
Working on a Tic-tac-toe game

 

anything