Question

以下是我的情景：

玩家将手指或鼠标放在屏幕底部的“原位”标记处。

计时器开始计数到500毫秒，如果用户在那段时间内没有举起手指或标记，则触发holdTimerElapsed。

在此方法中，我们显示下一个标记，延迟时间在500毫秒到1秒之间（因此用户有机会看到下一个目标）。延迟后，播放音频“GO”并启动计时器。

在计时器启动方法内：

private void StartTimer()
{
    startTime = DateTime.Now;
    timer.Interval = ConfigurationService.GameConfig.MarkerTimeLimit;
    timer.AutoReset = false;
    timer.Start();
}

我们记录＆＃34;开始时间＆＃34;那些运动。如果用户能够点击在规定时间（4.5秒）内弹出的下一个目标，我们会调用停止计时器方法：

private void StopTimer()
{
    stopTime = DateTime.Now;
    timer.Stop();
}

我的问题：

＆＃34;随机＆＃34;结果：

TimeSpan time = stopTime - startTime;

减去500毫秒的保持时间将是不切实际的2-5毫秒 - 对于除机器人以外的任何人来说都是不可能的移动时间。

我完全不知道为什么日期时间如此接近会产生如此小的结果。

更多代码：

private void HandleMarkerClick(ScatterCircle selectedCircle)
{
    StopTimer();
    selectedCircle.Aquired = true;
    aquiredTrainingCircles.Add(selectedCircle);
    TimeSpan time = stopTime - startTime;
    // movementTime here 'randomly' ends up as <10ms
    long movementTime = (long) time.TotalMilliseconds - ConfigurationService.GameConfig.MarkerHoldTime;  
}

在这种情况下，我只处理毫秒级的基准标记运动，它们需要相对准确，任何小于100毫秒的通常都是“快速实现”＃34;

Answer 1

为了结束这个问题，我接受了Jon Skeet的建议并转到了Stopwatch课程。客户仍然有不一致的结果。

我无法重现这个问题，长话短说，客户端在省电模式的笔记本电脑上运行应用程序，我认为这导致了不一致。

从节电模式切换到高性能似乎在很大程度上解决了这个问题。

C＃减去DateTimes给出了不切实际的结果

1 个答案: