I'm developing a 3D tower defense-like game in C++/OpenGL on Windows.

The problem I'm having isn't about the game itself (the game runs fine), but it's about using screen recording software to record gameplay.

For some reason, whenever I try to record the screen (I've tried both Camtasia Studio 8 and Fraps 3.5.9), it slows down the game (I'm not talking about just an FPS drop; the actual game timers run slower).

To show an example of what I mean, see the following screenshot: I ran two instances of my game at once (side by side), and recorded the righthand one using Fraps. As you can see in the image below, Fraps is causing the game time for the recorded instance to increase almost twice as slowly as it should.

Time bug

I'm getting around 800-1000 FPS when running the game without Fraps recording, and around 300-400 FPS with Fraps recording. But playing the game with recording causes everything to happen in slow-motion, despite it running smoothly rendering-wise.

For timing I've tried using both the QueryPerformanceCounter() and timeGetTime() approaches - the slowdown still occurs using either.

Does anyone have an idea what might be causing this? Could it be because of the way I'm rendering with OpenGL?

  • \$\begingroup\$ The question to you is, is your pc even capable of doing both things at the same time? Have you tried changing the render settings? Some recording tools are optimized to run in fullscreen directX and OpenGL specifically for games. \$\endgroup\$ – Sidar Feb 27 '13 at 5:56
  • 4
    \$\begingroup\$ @Sidar If it's still rendering at 300-400 fps, then the pc is completely capable of doing both things at the same time. My suspicion is that Ryan's not actually using the timers for anything -- that the things which feel "slow" are things which happen once-per-frame. That if you (Ryan) frame-limited yourself to 60fps (by enabling vsync, for example), you'd find that things felt even slower. My intuition is that your problem is that your game speed is locked to your framerate, so I'd suggest investigating that, before thinking too much about FRAPS or etc. \$\endgroup\$ – Trevor Powell Feb 27 '13 at 6:49
  • 1
    \$\begingroup\$ I'm guessing it's what Trevor said: your code is not doing things the way you think it is. Of course, since you didn't provide the code, we can't confirm this. \$\endgroup\$ – Nicol Bolas Feb 27 '13 at 8:00
  • \$\begingroup\$ It's not framerate limited; the game only runs at around 80 FPS on my laptop during high action, with no slow down. I would be more than happy to provide code, but it would take several hundreds of lines to show some representative example. I can't figure out where to start narrowing this down. \$\endgroup\$ – Ryan Berserkguard Nørby Feb 27 '13 at 9:27

FRAPS actually reads from the OpenGL and DirectX video buffers to record videos. The good news is that in order to make FRAPS work is use OpenGL/DirectX. The bad news is that there will be some overhead as the computer has to do one more thing with the video buffer as apposed to the usual read/draw operations.

Also consider FRAPS will clobber your Hard-Drive with Video data. If your game needs the hard drive, or your system is big on virtual memory, you will notice a large performance hit.

To make your game work regardless, consider time-locking your program loops. Sprites should only move the distance based off the velocity times the time since the last loop, Frames should only change if the seconds per frame (1/FPS) has been met or exceeded since the last frame change.

  • \$\begingroup\$ Turns out I was calculating delta time incorrectly! At the beginning of the game loop I had start = engine->getSystemManager()->getTime(); And at the end of the loop I had delta = engine->getSystemManager()->getTime() - start; This worked well in all cases except for recording. I modified the code to calculate the delta all at once, using: oldtime = newtime; newtime = engine->getSystemManager()->getTime(); delta = newtime - oldtime; And this fixed the problem. It also made the movement a lot less jerky! \$\endgroup\$ – Ryan Berserkguard Nørby Mar 1 '13 at 6:03

You timing code should look something like this. Does this function work correctly if you put it in your code somewhere and call it every frame?

void PrintTimeRemaining(void)
    // This static is just a hack to simplify the code. You'd normally put it in a class member.
    static int target = timeGetTime() + 100 * 1000; // 100 seconds

    char string[256];
    int remaining = target - timeGetTime();

    sprintf(string, "Time remaining: %d.%03d seconds\n", remaining / 1000, remaining % 1000);

    // Print the string out to the debug output window for testing
  • \$\begingroup\$ I just tried this: in my game loop I printed it to the console once every ten seconds (using my current timing code), and all the numbers printed were 10 seconds apart. However, when I'm recording the game, the actual time passed between the printings is closer to 20 seconds, but a 10-second difference is still being printed. \$\endgroup\$ – Ryan Berserkguard Nørby Mar 1 '13 at 4:52
  • \$\begingroup\$ The reason I gave you new timing code was that I suspected your existing timing code was wrong. \$\endgroup\$ – Adam Mar 2 '13 at 11:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.