Messages

1

SFML projects / Re: Simple Fast SFML Physics

« on: June 30, 2022, 07:19:18 pm »

There's one thing you should never do when making a C++ library, and that is putting "using namespace std;"  globally in a public header.

The reason is that a you're forcing "using namespace std;" to anyone who uses your library, and lot of people don't like having "using namespace std;" in their code.
So be considerate to your users and don't force that on them.

Fortunately there's a quick and dirty way to alleviate this issue, and that is to simply put the using directives inside your namespace.

Code: [Select]


namespace sfp {

    //This is now inside your namespace sfp
    using namespace std;
    using namespace sf;


This isn't ideal (personally I wouldn't put using directives in headers files) but it is a minimum standard that is really quick to achieve.

2

General / Re: CMake include problem

« on: June 13, 2021, 03:59:44 am »

You would need to add this to your CMake script.

target_link_libraries("window" PUBLIC
    "sfml-graphics"
    "sfml-audio"
)
 

3

General / Re: Shape not moving

« on: April 10, 2020, 03:19:35 am »

Oh! Thanks. It wasn't deliberate. I didn't get any warning though

If you're using GCC, you can enable the warning with -Wshadow.

I compiled the two programs(after correcting) and they behave very differently. In the one with the bool variable to store the state, the shape disappears when tried to move. In the second program(which uses isKeyPressed()) the circle moves smoothly. Why is there a difference of behavior?

It's because you're invoking undefined behaviour.

void Game::update(){
    sf::Vector2f movement(0.f, 0.f);
    if(is_moving_up)
        movement.y -= 1.f;
    if(is_moving_down)
        movement.x += 1.f;
    if(is_moving_left)
        movement.x -= 1.f;
    if(is_moving_right)
        movement.x += 1.f;
   
    m_player.move(movement);
}
 

In this function there's no guarantee that is_moving_up, is_moving_down, is_moving_left, is_moving_right have been initialised yet, so this function will act unexpectedly.

Please note that a boolean member variable are not initialised by default, so you have to make sure it's initialised. You can do it in the constructor or the class definition.

4

General / Re: Problem with compiling in windows (mingw)

« on: January 16, 2020, 12:04:26 am »

Code: [Select]

g++ -std=c++14 -I../thirdparty/SFML-2.5.1/include -L../thirdparty/SFML-2.5.1/lib -lsfml-graphics -lsfml-window -lsfml-system main.cpp -o main.o

You put your files after the sfml libraries when you should have put it before.
(Also the -o flag is for specifying your output file e.g. an .exe not an object file.)

So try this:

Code: [Select]

g++ -std=c++14 -I../thirdparty/SFML-2.5.1/include -L../thirdparty/SFML-2.5.1/lib main.cpp -lsfml-graphics -lsfml-window -lsfml-system  -o insert_name_here.exe


5

General / Re: Segmentation Fault

« on: January 10, 2020, 01:23:17 pm »

std::vector<sf::Texture> texturas;
 

Putting sf::Texture in an std::vector is going to cause you issues.

Sometimes when you call push_back on an std::vector it causes reallocation, so the elements move to another location. 
If there were some pointers pointing to those elements, those pointers will become invalid. 
You can check this stackoverflow answer on iterator invalidation.

Because of this, I don't think std::vector is a good choice for storing textures, since you'll have pointers to elements. 


However here's the source of your current issue.

corpo.setTexture(texturas[0]);
 

You're indexing out of bounds here.
You're trying to get the first element (remember arrays start at 0), but at this point texturas has no elements.

texturas.reserve(10);
for (i=0; i < texturas.size(); i++) {
    texturas[i].loadFromFile("Idle (" + std::to_string(i+1) + ").png");
    texturas[i].setSmooth(true);
}
 

Here is another example of you indexing out of bounds.
Reserve doesn't do what you think it does. It does not change the size of the vector.
What you want to do is resize.

(Also why is i a member variable? It should really be local since you only use it here.)

6

General / Re: Vectors of texture and sprite

« on: December 11, 2019, 04:23:59 am »

Sometimes when you call push_back on an std::vector it causes reallocation, so the elements move to another location. 
If there were some pointers pointing to those elements, those pointers will become invalid. 
You can check this stackoverflow answer on iterator invalidation.

Because of this, I don't think std::vector is a good choice for storing textures, since you'll have pointers to elements. 
You may want to choose a container that doesn't invalidate pointers to elements when inserting, e.g. list or map.

7

General / Re: SFML CMake error

« on: November 11, 2019, 02:01:57 pm »

Just realised that.

Using command prompt admin rather than the regular command prompt allows me to install SFML into Program Files.

Not sure why there isn't a way to directly open command prompt admin from the folder, so I don't have to copy the path.

8

General / Re: SFML CMake error

« on: November 10, 2019, 06:44:11 pm »

Well it seems like I've got this fix.

Apparently, MinGW doesn't like paths with spaces in them, so I had to move it away from Program Files and to somewhere else.

The build process works 100%.

However the installation has an error:

Code: [Select]

-- Install configuration: "Release"
-- Installing: C:/Program Files/SFML/./include
CMake Error at cmake_install.cmake:36 (file):
  file INSTALL cannot make directory "C:/Program Files/SFML/./include": No
  such file or directory.

  Makefile:72: recipe for target 'install' failed
  mingw32-make: *** [install] Error 1


Edit: Checked the tutorial and changing CMAKE_INSTALL_PREFIX fixes this.

9

General / SFML CMake error

« on: November 10, 2019, 06:18:19 pm »

I'm trying to build SFML with CMake using this tutorial.

Now I've managed to make the makefile with CMake.

However if I tried to build SFML using the "mingw32-make install" command I get this error.

Code: [Select]

[  1%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.
obj
'C:\PROGRA~1\MinGW\MINGW' is not recognized as an internal or external command,
operable program or batch file.
src\SFML\System\CMakeFiles\sfml-system.dir\build.make:62: recipe for target 'src
/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj' failed
mingw32-make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.obj]
Error 1
CMakeFiles\Makefile2:215: recipe for target 'src/SFML/System/CMakeFiles/sfml-sys
tem.dir/all' failed
mingw32-make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
Makefile:128: recipe for target 'all' failed
mingw32-make: *** [all] Error 2


10

Graphics / Re: Array of shapes

« on: October 18, 2019, 11:55:11 pm »

Long time, but, since I am optimizing now my game - I was trying to do so by changing way of iterating.

So, due to my Visual Studio profiler - when using auto c++11 vs using index, auto construction is slower by about 5% (and I fps are going down from ~2000 to 1500) - I am drawing about 120  sprites...

Are you compiling with optimization enabled?
And could you show your code?

11

General / Re: Start from .exe

« on: October 18, 2019, 04:23:41 pm »

Do you load assets (e.g. texture, sounds, etc) in your program? Are they in same directory as your .exe?

Try modifying your project working directory.

12

SFML development / Re: sf::NonCopyable and =delete

« on: October 18, 2019, 04:20:25 pm »

Going to give my 2 cents on this old thread. IMO the concept of NonCopyable isn't as useful as it was in C++03, it now split into 2 concepts now: MoveOnly and NonMoveable.

I'll say that NonCopyable is kinda redundant giving that you can to the same thing with =delete.
E.g. Foo& operator=(Foo&&) = delete; will do the same thing as Foo inheriting from sf::NonCopyable in 1 line.

13

Window / Re: Getting segfault at RenderWindow method callings

« on: September 21, 2019, 04:52:48 pm »

You're program seemed to segfault on this line.

m_grid[col][row] = nullptr;
 

It's because you're indexing the matrix out of range (which is undefined behaviour) as you got the row and column backwards. You should be doing m_grid[row][col] instead.
Note that [] doesn't do range check, so if you want to range checking you can use .at().

Another issue is this line.

m_window( *new sf::RenderWindow(sf::VideoMode(COLS*CELL_SIZE,
        ROWS*CELL_SIZE),"Test") )
 

Is there a reason why you're initialising m_window is like this? You could simply make m_window not a reference, and just initialise it normally.

m_window( sf::VideoMode(COLS*CELL_SIZE,
        ROWS*CELL_SIZE),"Test")
 

This way you avoid the unnecessary dynamic allocation.

When you do need to use dynamic allocation. It's best to avoid explicit new when possible, as there's usually better alternatives, such as unique_ptr and shared_ptr. Learn about RAII, and you can reduce error-prone manual resource management.

Another issue is that your Life class is has no virtual destructor. Polymorphic base classes need one to prevent undefined behaviour. It's quite simple to so.

class Life : public sf::Drawable
{
public:
//....
    virutal ~Life() = default;
};
 

As usual when you're defining destructors, you should be aware of the rule of 5.


Well that's the major issues, onto the very minor things.

Minor things that you may want to know. Firstly sf::Noncopyable also deletes the move functions as well as copy which may not be what you want. Secondly, it is preferably for the constants at the top (ROWS) to be constexpr instead of const, so you don't get compiler errors down the road. Thirdly, if you want scoped enums you can you enum classes as it also provides strong typing. Fourthly, having both virtual and override in a function declaration is redundant as you cannot override a non-virtual function, so you can simply just have override.

14

General discussions / SFML Book order

« on: August 29, 2019, 12:20:57 am »

Hello, I would like to know which SFML book should I read first, and which order should I read them.

15

General / Re: Need help with keeping an process going even after a key has been pressed

« on: August 26, 2019, 05:15:40 pm »

Thank you sooo much for pointing these things out I really really appreciate it .
I do have one question tho why is it so important to have the keypressed event in the event loop cause it totally works in where I had it. will it cause problems later on?? or is it just good practice to do so?

Checking for events outside of the event loop means that you will only check for the last event per frame. This can cause issue, for example if you press the pause button and move the mouse at the same time, there will be 2 events: a KeyBoard event and a Mouse event, however your code will only check for only 1 event, so sometimes if you press pause, it would not pause.

By checking for events in the event loop, you will check for all the events rather than just one, so it will always work.