So SDL thinks that every frame takes exactly 1 ms? That seems suspicious to me. Have you tried setting up your own timer and seeing how long each frame takes? I'm guessing there's something wonky going on there.

When you have very low time values, physics systems can start to break down due to floating point precision. (Mike talks about this in his Gotcha on page 574.)

-Rez

I'm guessing SDL_GetTicks() just wraps GetTickCount() or something similar. If you set a breakpoint for 10 seconds, do you actually 10,000ms? As in, exactly? I'm guessing that you're hitting some limit in SDL since your demo is likely running way faster than SDL can deal with.

Try artificially limiting the framerate of your game to 60 fps. This definitely isn't something you want to ship with, but it'll be an interesting test to see if your physics universe realigns itself. That should give you something around 17ms, which may be better. You can also try 30 fps, which should give you results around 33ms.

Floating point precision can really screw you over. I think that's what's happening here.

Incidentally, I'm dealing with something similar at work right now. There's an inconsistency between a timed event (an event that triggers after a certain amount of time has elapsed) and the decay of a statistic. They are often off by about 0.00005. Floating point precision make me sad.

-Rez

Yeah, something like:



I think the function itself takes a float, so it would get truncated at that point.

-Rez

You shouldn't have to lie to the physics simulation. Mike did the Physics integration so he'd be able to tell you if there's something specifically wonky with Bullet, though looking at the code, it appears that we just pass the time in directly:



Nothing jumps out at me as being wrong with the code. GetTickCount() (which SDL_GetTicks() likely wraps) is notoriously bad for high-resolution timing. If you're trying to time things that are 10ms - 16ms or less, you'll get very erratic results. Check out the remarks on the MSDN page:
msdn.microsoft.com/en-us/library/windows/desktop/ms724408(v=vs.85).aspx

You may want to try using a higher resolution timer. Another possibility is to just sleep for 20ms as a hack. The problem with the method I suggested to you is that if the frame only took 5ms, GetTickCount() may return as high as 16ms. If the next frame took 10 ms, you might get 16ms again. As you can see, this will cause erratic behavior.

As for some frames dropping to 3 fps, I'm sure what's happening there, although you are spamming the title bar with framerate info as well as dynamically allocating and deallocating that string. That's likely to be very slow. Maybe profile it and see what's happening?

By the way, you don't need to dynamically allocate the string. You're already allocating a static amount of memory, so just declare the array directly:



That'll be MUCH faster than thrashing memory.

-Rez

Rez will probably hate this, but here's my inner loop, which seems to work well enough for getting non-zero deltas.

while(Engine::Instance()->IsFinished() == false)
{
MSG message;
if (PeekMessage(&message, nullptr, 0, 0, PM_REMOVE) != 0)
{
TranslateMessage(&message);
DispatchMessage(&message);
}
else
{
static long timer = 0;
long delta = clock() - timer;
timer = clock();

Engine::Instance()->Update(delta);
Engine::Instance()->Render();
SwapBuffers(EntropicHDC); // Using OpenGL double buffering.

// Sleep one millisecond to avoid running faster than the resolution of clock()
// Plus this isn't remotely resource constrained, so it will still easily do 60 fps
Sleep(1);
}
}

James

Sleeping for 1 ms probably wouldn't effect this much. As far as I know, Sleep() is not bound to the low-resolution timer used by GetTickCount(), it's bound to the system clock (which is higher-resolution). Either way, adding an arbitrary Sleep() call is definitely a hack, unless you pass in 0 as the parameter, which just causes the current thread to yield.

Still, having some kind of false performance load can help simulate what your game will actually do. When I was writing my multi-threaded renderer, I had a Sleep(1) in there because my logic thread was literally an empty function. Turns out this was causing the app to starve the OS of CPU cycles. A simple Sleep() call fixed that. I was able to remove it once I had the engine rendering and doing something useful in the logic thread.

Like I said before, I would put in a much higher value just to test. Something around 20ms.

-Rez

I wouldn't bother at this stage in the game. It'll just confuse the issue further. Threads add a level of complexity that you probably don't need for most simple games. You should only resort to threads if you're trying to solve a specific problem in your game.

-Rez

I have been using GetSystemTime for my game timing and for timing my function/process durations. Is this a bad way to do this? What do professonal programmers use for high-resolution timers? Has anyone played with the QueryUnbiasedInterruptTime? MSDN says that it has issues with inconsistent results on systems with multicore processors.