Project runs extremely glitchy on Linux with the same source code as on windows

[Cupcake26699]

I have a game that I am basing much of the source code off of from the SFML Gamedev Book Code. When I compiled the game on windows it ran just how I expected, no major glitches or anything like that. However when I ported it to Linux using Code::Blocks and the same SFML version (2.3.2) I am getting major glitches that I can only guess are related to multi-threading.

The following glitches I have noticed occur:

• Large amount of segmentation faults that randomly happen when switching states (example: going from menu screen to game screen)
• Guns fire at least 5 times as faster on multiplayer game mode
• Grenades (which are meant to slow down overtime) often get thrown at extreme speeds

What possible reasons could this occur? The code is the same from before (on windows). Is this a fault with my compiler settings?

Here are my linker settings. Release and debug settings are both the same.

• sfml-system
• sfml-window
• sfml-graphics
• sfml-audio
• sfml-network

Any help would be appreciated.

[Jesper Juhl]

Are you using a version of SFML compiled with the *exact* same compiler that you build the rest of your code with?
Are you mixing debug and release (optimized) builds?
Are your OpenGL/GPU drivers up-to-date?
Do you have any global sf:: objects (don't)?
Are you sure it's not just bugs in your code (things like compiler warnings , asan , tsan , ubsan , clang-tidy may help)?

[Cupcake26699]

My answer is yes to all of what you said except using the same compiler that I build the rest of my code with. I am not aware that this could cause problems, so I will try and compile SFML on my own using GCC 4.9.

EDIT:

Should probably say no to having global objects and to mixing debug and release builds

[Arcade]

Some of these issues, such as objects moving faster than expected, sound like they might be due to how you set up your game loop. Does your game loop take into account that the frame rate may not be a constant value and might be different on your Linux machine vs Windows?

[Cupcake26699]

Yes, just like in the book my project uses a semi-fixed timestep. Also, the code is exactly the same as on windows, but these issues only appear on my linux setup (with the exact same source code)

[Cupcake26699]

After compiling SFML with Cmake using Unix Makefiles and sudo make the issues are still as prevalent as before. I'm unsure what I can do now.

[Nexus]

Also, the code is exactly the same as on windows, but these issues only appear on my linux setup (with the exact same source code)

As this thread clearly shows, the fact that you use the same code on another operating system with another compiler is no guarantee that the executable has the same behavior.

It's very likely that your code contains bugs, possibly because you assume certain behavior (of the C++ language, of the compiler, a library, ...) that is not guaranteed. Try to debug it with Code::Blocks and see what parts don't work as expected.

I am getting major glitches that I can only guess are related to multi-threading.

Do you use multi-threading? Because the book does not (apart from one example of a loading screen)... If you do, you should probably avoid it until you get your application running correctly.

[Jesper Juhl]

My answer is yes to all of what you said except using the same compiler that I build the rest of my code with. I am not aware that this could cause problems

This can easily cause problems. Using the exact same compiler for libraries and your application code should be the first item on your check-list.

[Cupcake26699]

I will try to further pinpoint what exactly is causing the crashes and randomness.

I was under the impression that playing sound was handled using threads, not in my code but in SFML itself. I might be wrong though.

[Nexus]

I was under the impression that playing sound was handled using threads, not in my code but in SFML itself. I might be wrong though.

That's true, but that alone doesn't randomly mess up your own code

You could try to reduce your application as much as possible, and find a minimal code that still reproduces the issue.

[grok]

as for segmentation faults: debugger is your friend (gdb in Linux), of course, you need to recompile your project in debug without optimizations flags and then investigate your coredump file with it. it should/might shed some light on what's going on.
in the simplest form run

gdb executable corefile
 

and see what happens.

[Cupcake26699]

I am using the CodeBlocks debug mode. It has helped me figure out which class and which object is causing the random segmentation faults. Just need to figure out why. This class is the weapon class, so it might have something to do with guns firing at extreme speed.