SDL->SFML conversion; very strange performance issues

[Laurent]

What consumes most of the CPU in SFML are calls to the Draw function. The fact that your program is equally slow even when you draw nothing, makes me think that you may have a problem in your own code -- which can be solved.

As soon as you provide a code which is minimal enough, we can start investigating and hopefully spot the problem.

[model76]

Do you really want to create a new World object every frame?

[ChonDee]

Do you really want to create a new World object every frame?

I am pretty sure there is only one world object created altogether.
There are 2 while loops.
The inner one does whatever is happening every frame.
The outer one goes if the player dies and the level is restarted. This is when the world object is reinitialized.

[model76]

You're right, I was a little fast there, sorry.

I downloaded your project, and it didn't take long to figure out that your two biggest culprits are Player::show_particles and Star::show.

There, that should help you come up with a minimal code that reproduces the problem.

I found the code pretty messy, so I didn't poke around for too long, but you do have a whole bunch of implicit casts that the compiler complains about. Maybe fixing those would be a good start.

Hope that helps!  

[ChonDee]

You're right, I was a little fast there, sorry.

I downloaded your project, and it didn't take long to figure out that your two biggest culprits are Player::show_particles and Star::show.

There, that should help you come up with a minimal code that reproduces the problem.

I found the code pretty messy, so I didn't poke around for too long, but you do have a whole bunch of implicit casts that the compiler complains about. Maybe fixing those would be a good start.

Hope that helps!  

Thank you,

Yes, the code is messy as this was my smallest, earliest build of the project that now is about 8K lines, divided into 20 header and cpp files, using a lot of images and sprites, I thought for my purposes of transitioning to SFML from SDL it will be okay if I try to convert this.

Obviously the show::particle took up most resources, especially since I (purposefully) increased the total particles shown 20x, to measure performance. In the SDL build it was going fine, here not so much.

on the gamedev forums I have actually been told, that the reason for this to strain SFML so much is because what opengl calls are made for each created particle, which is quite expensive.

They too suggested that I transition to SFML 2.0, as it is supposed to handle handle object sharing the same image much better, as Laurent also have told me about it earlier.

So now I am in the middle of trying to build SFML 2.0, then I will try to learn the new input functions.

After that I take a deep breath and rewrite my up-to-date build to SFML2.0.

Thanks for all your help, I won't go further into this particle drawing performance issue until I have fully transitioned my whole project to SFML 2.0.

[Laurent]

on the gamedev forums I have actually been told, that the reason for this to strain SFML so much is because what opengl calls are made for each created particle, which is quite expensive.

If you don't draw there's no OpenGL call at all. Creating particles (at least the SFML part of it) consumes 0 CPU. Remember what I said above.

[ChonDee]

on the gamedev forums I have actually been told, that the reason for this to strain SFML so much is because what opengl calls are made for each created particle, which is quite expensive.

If you don't draw there's no OpenGL call at all. Creating particles (at least the SFML part of it) consumes 0 CPU. Remember what I said above.

I see.
I am not sure what must have been the issue, now I have built SFML 2.0 according to the tutorial, and started a new VS project, set it up to SFML 2.0 libraries, changed the sf::image to sf::Texture, and I do not have performance issues, but I am not increasing the particle count to unreasonable numbers either.

It seems like things are working right now, I'll figure out SFML 2.0's input, then rewrite everything.

EDIT:
Actually, just to test it, now I have set the particle count 20x higher, like I was testing with 1.6 before

With 1.6 I got 38 FPS
With 2.0 I am getting 120+FPS

[ChonDee]

Okay, so now I have made the keyboard inputs with 2.0's functions.

In the main loop for every frame I use this to poll for events:

Code: [Select]

while (App.PollEvent (Event))
{
//myWorld.myPlayer.handle_input();
//if (Event.Type == sf::Event::Closed)
//{
// App.Close();
//}
}

sf::Event Event; is created once, globally.

So my problem now is, that regardless of what is inside the poll loop, even if it is empty, like above, the performance drops significantly, the frame rate fluctuates between 20-60.

Am I doing the polling wrong?

[Laurent]

Can you try to comment line 121 of src/SFML/Window/WindowImpl.cpp (ProcessJoystickEvents();) and recompile SFML?

[ChonDee]

Can you try to comment line 121 of src/SFML/Window/WindowImpl.cpp (ProcessJoystickEvents();) and recompile SFML?

Yes, that solved it!
Thank You

[Laurent]

This problem is really annoying :?

[Serapth]

This problem is really annoying :?

Is it happening consistently, or just on random installs?

[Laurent]

It seems to happen randomly, on PCs that sometimes have a joystick connected (PCs where no joystick is used at all are fine).

[ChonDee]

It seems to happen randomly, on PCs that sometimes have a joystick connected (PCs where no joystick is used at all are fine).

I had a usb xbox 360 wireless adapter connected (the controller wasn't paired up with it) while i was experiencing the performance drop, in case it helps.

[Laurent]

I had a usb xbox 360 wireless adapter connected (the controller wasn't paired up with it) while i was experiencing the performance drop, in case it helps.

I think it's enough to trigger the problem.