Quote:Original post by Lode

If I profile the application (with the profiler of devc++, which is by the way 1000x slower than gprof in Linux: gprof takes 0 seconds to output you a text file, devc++ takes 5 minutes to output the same text file in a window where you can't copypaste the text), it doesn't show what's causing the slowness.

There's an easy solution to this problem: don't use Dev-C++. [smile]

Quote:Original post by Lode

Could you describe this more? What does a rounding or accuracy issue mean in the context of timing?

An inaccurate timer gives you an inaccurate fps measurement. Games tend not to wildly vary in performance from frame to frame unless the scene drastically changes, or something else in the system changes. The simplest timer available in Windows, GetTickCount, is notoriously inaccurate. QueryPerformanceFrequency/QueryPerformanceCounter tends to be the API of choice for most games on Windows, although you need to take some care when using them.

Ah!
The FPS timer can't be the problem then: I use SDL's getticks, but also I take the average of the last 50 frames. So if the FPS changes, you see it settle to the new value. So if it says 11 fps, it really means that for 50 frames long it has been that slow, and the values I posted stay stable for minutes.

Also, I'm not just reading this FPS from a number. The FPS around the 11 FPS range is noticable by simply seeing how "fast" it's redrawn.

[Edited by - Lode on March 18, 2008 1:35:20 PM]

SDL_GetTicks actually uses QPC/QPF on Windows, so that's definitely not your problem then. [smile]

Quote:Original post by MJP
SDL_GetTicks actually uses QPC/QPF on Windows, so that's definitely not your problem then. [smile]

Except if one of the many known bugs with QPC/F occur ;)