• Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a \$50 Amazon gift card. Click here to get started!

### #Actualtonemgub

Posted 08 November 2013 - 12:16 AM

start = std::chrono::system_clock::now(); //Do work end = std::chrono::system_clock::now();

You're just timing your "work" here, not the time each frame takes - the time between frames, which is what's important.

Try this:

static std::chrono::time_point<std::chrono::system_clock> last = std::chrono::system_clock::now();

//Do work

std::chrono::time_point<std::chrono::system_clock> current = std::chrono::system_clock::now();
std::chrono::duration<float> elapsed_seconds = current - last;
last = current;

float timer = elapsed_seconds.count() * 1000f;
std::cout<< "Frame Time: " << timer << "ms\n";

This should give you a better a idea of how much time each frame takes.

Also, since the timer precision might not be reliable, you could try looking at the average duration of all frames - just count the frames, then divide the total time by that count. It should stay somewhere around 16.6 . If not, then something is causing some of your frames to be dropped.

I think I saw the same kind of stuttering with Direct3D once - in my case it was because I was doing some double-precision calculations, and Direct3D kept putting the FPU into single-precision mode every frame - and the FPU precision switch is apparently very costly. But AFAIK, OpenGL shouldn't suffer from this.

EDIT: I just looked at your code on github. I don't know much SDL, but I noticed you're using SDL_PollEvent to get the ESC keypress - you might want to remove that, just to be sure it's not what's causing the stutter.

Also: why are you doing glClear AFTER SwapBuffers?

### #5tonemgub

Posted 08 November 2013 - 12:09 AM

start = std::chrono::system_clock::now(); //Do work end = std::chrono::system_clock::now();

You're just timing your "work" here, not the time each frame takes - the time between frames, which is what's important.

Try this:

static std::chrono::time_point<std::chrono::system_clock> last = std::chrono::system_clock::now();

//Do work

std::chrono::time_point<std::chrono::system_clock> current = std::chrono::system_clock::now();
std::chrono::duration<float> elapsed_seconds = current - last;
last = current;

float timer = elapsed_seconds.count() * 1000f;
std::cout<< "Frame Time: " << timer << "ms\n";

This should give you a better a idea of how much time each frame takes.

Also, since the timer precision might not be reliable, you could try looking at the average duration of all frames - just count the frames, then divide the total time by that count. It should stay somewhere around 16.6 . If not, then something is causing some of your frames to be dropped.

I think I saw the same kind of stuttering with Direct3D once - in my case it was because I was doing some double-precision calculations, and Direct3D kept putting the FPU into single-precision mode every frame - and the FPU precision switch is apparently very costly. But AFAIK, OpenGL shouldn't suffer from this.

EDIT: I just looked at your code on github. I don't know much SDL, but I noticed you're using SDL_PollEvent to get the ESC keypress - you might want to remove that, just to be sure it's not what's causing the stutter.

### #4tonemgub

Posted 08 November 2013 - 12:04 AM

start = std::chrono::system_clock::now(); //Do work end = std::chrono::system_clock::now();

You're just timing your "work" here, not the time each frame takes - the time between frames, which is what's important.

Try this:

static std::chrono::time_point<std::chrono::system_clock> last = std::chrono::system_clock::now();

//Do work

std::chrono::time_point<std::chrono::system_clock> current = std::chrono::system_clock::now();
std::chrono::duration<float> elapsed_seconds = current - last;
last = current;

float timer = elapsed_seconds.count() * 1000f;
std::cout<< "Frame Time: " << timer << "ms\n";

This should give you a better a idea of how much time each frame takes.

Also, since the timer precision might not be reliable, you could try looking at the average duration of all frames - just count the frames, then divide the total time by that count. It should stay somewhere around 16.6 . If not, then something is causing some of your frames to be dropped.

I think I saw the same kind of stuttering with Direct3D once - in my case it was because I was doing some double-precision calculations, and Direct3D kept putting the FPU into single-precision mode every frame - and the FPU precision switch is apparently very costly. But AFAIK, OpenGL shouldn't suffer from this.

### #3tonemgub

Posted 08 November 2013 - 12:04 AM

start = std::chrono::system_clock::now(); //Do work end = std::chrono::system_clock::now();

You're just timing your "work" here, not the time each frame takes - the time between frames, which is what's important.

Try this:

static std::chrono::time_point<std::chrono::system_clock> last = std::chrono::system_clock::now();

//Do work

std::chrono::time_point<std::chrono::system_clock> current = std::chrono::system_clock::now();
std::chrono::duration<float> elapsed_seconds = current - last;
last = current;

float timer = elapsed_seconds.count() * 1000f;
std::cout<< "Frame Time: " << timer << "ms\n";

This should give you a better a idea of how much time each frame takes.

Also, since the timer precision might not be reliable, you could try looking at the average duration of all frames - just count the frames, then divide the total time by that count. It should stay somewhere around 16.6 . If not, then something is causing some of your frames to be dropped.

I think I saw the same kind of stuttering with Direc3D once - in my case it was because I was doing some double-precision calculations, and Direct3D kept putting the FPU into single-precision mode every frame - and the FPU precision switch is apparently very costly. But AFAIK, OpenGL shouldn't suffer from this.

### #2tonemgub

Posted 07 November 2013 - 11:48 PM

start = std::chrono::system_clock::now(); //Do work end = std::chrono::system_clock::now();

You're just timing your "work" here, not the time each frame takes - the time between frames, which is what's important.

Try this:

static std::chrono::time_point<std::chrono::system_clock> last = std::chrono::system_clock::now();

//Do work

std::chrono::time_point<std::chrono::system_clock> current = std::chrono::system_clock::now();
std::chrono::duration<float> elapsed_seconds = current - last;
last = current;

float timer = elapsed_seconds.count() * 1000f;
std::cout<< "Frame Time: " << timer << "ms\n";

This should give you a better a idea of how much time each frame takes.

Also, since the timer precision might not be reliable, you could try looking at the average duration of all frames - just count the frames, then divide the total time by that count. It should stay somewhere around 16.6 .

And sorry, but I'll have to repeat the question the others asked: if you ignore how much time each frame takes, is the stuttering noticeable, as in: can it be picked up by the human eye? Sorry to repeat, but you never mentioned this clearly.

### #1tonemgub

Posted 07 November 2013 - 11:47 PM

start = std::chrono::system_clock::now(); //Do work end = std::chrono::system_clock::now();

You're just timing your "work" here, not the time each frame takes - the time between frames, which is what's important.

Try this:

static std::chrono::time_point<std::chrono::system_clock> last = std::chrono::system_clock::now();

//Do work

static std::chrono::time_point<std::chrono::system_clock> current = std::chrono::system_clock::now();
std::chrono::duration<float> elapsed_seconds = current - last;
last = current;

float timer = elapsed_seconds.count() * 1000f;
std::cout<< "Frame Time: " << timer << "ms\n";

This should give you a better a idea of how much time each frame takes.

Also, since the timer precision might not be reliable, you could try looking at the average duration of all frames - just count the frames, then divide the total time by that count. It should stay somewhere around 16.6 .

And sorry, but I'll have to repeat the question the others asked: if you ignore how much time each frame takes, is the stuttering noticeable, as in: can it be picked up by the human eye? Sorry to repeat, but you never mentioned this clearly.

PARTNERS