比无限循环+封锁更好的游戏循环? [英] Better game loops than endless loop + block?

问题描述

每个游戏教程和游戏框架(甚至是相当新的XNA框架)都从一个永无止境的循环开始，该循环具有等效的DoEvents()来防止操作系统锁定.

Every game tutorial and game framework (even the rather new XNA framework) start off with a never ending loop that has an equivalent of DoEvents() to prevent the OS from locking up.

从非基于游戏的角度来看，我觉得这种代码听起来很时髦.
没有更好的选择了吗?

Comming from a non-game based perspective I feel this kind of code smells rather funky.
Are there no better alternatives?

-编辑-
很多答案说每个程序基本上都是一个循环.是的，但是我觉得循环应该由您的操作系统执行，而不是您.只有OS拥有以最佳方式分配资源所需的所有信息.还是我在这里错过了重点?

--EDIT--
A lot of answers say every program is basically a loop. True, but I feel the loop should be performed by your OS, not by you. Only the OS has all the information it needs to distribute its resources in an optimal way. Or am I missing an important point here?

推荐答案

每个Windows应用程序的核心都有一个看起来像这样的循环:

Every Windows app has at its core a loop that looks something like this:

BOOL bRet;

while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0 ) 
{
   if (bRet == -1 )
   {
      // handle the error and possibly exit
   }
   else
   {
      TranslateMessage( &msg );
      DispatchMessage( &msg );
   }
}

确保消息被分发是应用程序的工作，而不是操作系统的工作.

It's the application's job--not the operating system's--to ensure that messages are dispatched.

您可能知道，早期的Windows游戏使用了另一种方法，即不调用阻塞GetMessage函数，而是调用PeekMessage，然后在没有消息可处理的情况下调用游戏的主处理循环.各种形式的延迟被用来尝试在不占用100％CPU的情况下获得足够的帧速率.只是没有足够好的计时器来提供平滑的帧速率.

As you probably know, early Windows games used an alternate method where, instead of calling the blocking GetMessage function, they'd call PeekMessage, and then call the game's main processing loop if there was no message to handle. Various forms of delays were used to try to get an adequate frame rate without taking 100% CPU. There just wasn't a good enough timer to give a smooth frame rate.

今天，可能没有必要显式地编写一个调用DoEvents的循环.通过内置的计时器池计时器(现在在.NET中由System.Threading.Timer公开，并由System.Timers.Timer包装)，现在可能获得平滑的帧速率.

Today, it might not be necessary to explicitly write a loop that calls DoEvents. It might be possible now to get a smooth frame rate by using the built-in timer pool timers (exposed in .NET by System.Threading.Timer, and wrapped by System.Timers.Timer).

我记得，及时获取鼠标和键盘事件也存在问题.我们使用直接的键盘和鼠标访问方式，而不是依赖于消息循环，因为消息循环通常太慢，有时会导致我们丢失信息.

As I recall, there were also issues with getting mouse and keyboard events in a timely manner. We used direct keyboard and mouse access rather than depending on the message loop, because the message loop was often too slow and sometimes would cause us to lose information.

我已经好几年没有写游戏了，而且我也不知道.NET作为游戏平台是什么样的.输入仍然可能是一个问题-消息队列根本不够快，无法给出游戏开发人员想要的闪电般的快速响应.因此他们绕过消息队列执行关键任务.

I've not written games in a number of years, and I don't know what .NET is like as a games platform. It's possible that input is still a problem--that the message queue simply isn't fast enough to give the lightning-quick response that game developers want. So they bypass the message queue for critical tasks.

这篇关于比无限循环+封锁更好的游戏循环?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！