2

After reading these questions:

Code is behaving differently in Release vs Debug Mode

C# - Inconsistent math operation result on 32-bit and 64-bit

Double precision problems on .NET

Why does this floating-point calculation give different results on different machines?

I suspect that the reason my method for determining FPS which works while in Debug mode and no longer works in Release mode is because I'm using Long to hold time values. Here's the relevant code:

public void ActualFPS()
    {
        if (Stopwatch.GetTimestamp() >= lastTicks + Stopwatch.Frequency)
        {
            actualFPS = runsThisSecond;
            lastTicks = Stopwatch.GetTimestamp();

            runsThisSecond = 0;
        }
    }

runsThisSecond is incremented by one every time the method I'm tracing is called. Granted this isn't an overly accurate way to determine FPS, but it works for what I need it to.

lastTicks is a variable of type Long, and I believe that Stopwatch.GetTimestamp() is returned as a Long as well(?). Is this my problem? If so: any suggestions as to how to work around this?

EDIT: Stopwatch is using the High Resolution timer.

EDIT2: The problem has resolved itself. Without any changes to any of my code. At all. None. I have no idea what caused it to break, or to fix itself. Perhaps my computer decided to spontaneously consider my feelings?

Community
  • 1
  • 1
Bloodyaugust
  • 2,463
  • 8
  • 30
  • 46
  • 2
    a long is a 64bit int, so it's not likely to overflow. However I suspect that Stopwatch.GetTimestamp() may be using the low resolution timer which means it has a 10ms or so granularity. – Larry Osterman Mar 06 '11 at 05:38
  • 1
    All of the questions you linked to are about **floating point operations**. Your code uses a `Long` (or `Int64`), which is an integer type. Totally different things, not likely to be the same problem. – Cody Gray - on strike Mar 06 '11 at 05:43
  • It's using the high resolution timer. Accurate within 615 nanoseconds. – Bloodyaugust Mar 06 '11 at 05:47
  • @blizpasta: I'm not expecting anything in particular. Essentially I'm firing everything inside the if loop every one second. It doesn't matter what exactly the values are. – Bloodyaugust Mar 06 '11 at 05:57
  • What is the difference in output? – Akash Kava Mar 06 '11 at 07:04
  • 1
    Since you haven't said *how* the release version behaves differently, I'm going to guess that you get 0 and use my psychic debugging powers to suggest that you're not incrementing `runsThisSecond` in Release mode. – Gabe Mar 06 '11 at 07:21
  • @Gabe: Alright, so I may have left some important info out of my question... Let's say I am getting 0 in Release. Why would runsThisSecond not increment in release when it does so just fine in debug? Would it being after a call to Application.DoEvents() have anything to do with it? – Bloodyaugust Mar 07 '11 at 04:54
  • Post the function that increments `runsThisSecond` and maybe it will be apparent why it's not running in Release mode. – Gabe Mar 07 '11 at 05:28

1 Answers1

3

You have a very accurate interval measurement available (gettimestamp - lastticks), but you are not using it all to compute the frame rate. You assume the interval is a second, it won't be. It will be more, by a random amount that's determined by how often you call ActualFPS(). In Release mode you'll call ActualFPS() more frequently so the error is less.

Divide runsThisSecond by (gettimestamp - lastticks) converted to seconds.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • The interval, as I understand it, is *by definition* one second, or at least how many ticks are in one second. Also, I'm reasonably sure that despite release mode running faster, it wouldn't cause a forty-five frame per second difference, especially since everything seems to be running at the same speed(part of it being a frame by frame animation, which is quite measurable). And I understand what you're suggesting in your post, but wouldn't converting "(gettimestamp - lastticks)" to seconds require using Stopwatch.Interval, which you just suggested is randomly (determined) calling ActualFPS()? – Bloodyaugust Mar 07 '11 at 05:07