Help! SDL slows down other code by over 50 times?

SDL Development
1

Hi there,

I ran into a strange problem with my project. When I changed the basecode, IDE and introduced VBO, the identical code suddenly slowed down by more than 50 times! After making some experiments, I think it might have something to do with SDL. Any one having similar observations?

My project so far has a very simple OpenGl 3D world and a flight simulator that uses physical simulation (needs a lot of CPU). I first programmed it with DEV-C++ on top of NeHe tutorial 14, which uses the old NeHe basecode. The program works so, that between drawing every screen, it measures the time from the previous update, and runs the simulation for correct amount of time steps to get the new position of the plane to draw the next screen. It ran smoothly with timestep of 0.001 seconds. :slight_smile:

Then I took New NeHe Lesson03 basecode which uses SDL, and switced to CodeBlocks IDE. Then I copy pasted my classes to it and added VBO support. The graphics run smoothly, but when I start the simulation (Code of which had not been touched), the framerate quickly slows down below 1! I have to change the simulation timestep to 0.1 before it’s able to maintain framerate. :frowning: Without simulation running, frame rate is about 60 (never exceeds, a system default?) so the graphics should not be a problem.

Removing all VBO code and switching back to DEV-C++ don’t help, so I think the problem is the third thing I changed, the SDL. Any ideas what to do?

This is the code I use in the draw function to run the simulation, each time before drawing anything. The class of the plane1, or any code it uses has not been changed:

Code:

deltaT = mTimer.getElapsedTime();
mTimer.restart();

for (float time=0.000f; time < deltaT; time+=timeStep)
{
plane1->takeTimeStep(timeStep);
}

So the for loop here suddenly takes more than 50 times more time. What to do? :?

2

Are you testing it on Windows, AND are you using SDL_PollEvent() for mouse input handling?

3

Yes I’m using Windows XP pro SP2. I’m not using SDL_PollEvent(). My code is basically the code of this tutorial: http://nehe.gamedev.net/wiki/NewLesson3.ashx And I haven’t changed it that much, so I think the problem could be in the basecode already, meaning that calling your own non-graphics code inside the draw function is very slow for some reason.

I did some tests with the older version (no SDL) and this new version that has SDL 1.2.13.

Old version, time step 0.001 (1000 physics calculations per second):
(Drawing everything in immediate mode)
Only graphics: 60 fps and 20% of CPU
Graphics + simulation 60 fps and 55% of CPU

New version, time step 0.05 (20 physics calculations per second):
(Using VBO, vertex arrays, or immediate mode makes no difference)
Only graphics: 60 fps and 20% of CPU
Graphics + simulation <1 fps and 55% of CPU

So the simulation takes about 35% CPU both ways, but the new version does 50 times less calculations and still can’t maintain fps. And the new version will not take all available CPU. The old version will take all available CPU, before fps starts dropping. And 60 fps seems to be some kind of system default in all cases.

4

I have made further tests and it seems that this issue is not connected to SDL. I rewrote the base code classes Window and Lesson using Windows API and didn’t touch anything else. This replacement didn’t have noticeable effect on performance, so SDL is not to be blamed.

Good thing is that there’s no reason to dump SDL. Bad thing is that my problem is not solved.