Лучше игровые петли, чем бесконечный цикл + блок?

Question

Каждый игровой учебник и игровая среда (даже довольно новая инфраструктура XNA) начинаются с бесконечного цикла, который имеет эквивалент DoEvents(), чтобы предотвратить блокировку ОС.

Исходя из соображений, не связанных с игрой, я чувствую, что этот код довольно пахнет.
Нет ли лучших альтернатив?

--EDIT--
Много ответов сказать, что каждая программа находится в основном петля. Правда, но я считаю, что цикл должен выполняться вашей ОС, а не вами. Только ОС имеет всю необходимую информацию для оптимального распределения своих ресурсов. Или я пропустил важный момент здесь?

Answer 1

приложения для Windows Каждый имеет в своей основе цикла, который выглядит примерно так:

BOOL bRet; 

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

Это работа приложения - не рабочие system - чтобы гарантировать, что сообщения отправляются.

Как вы, вероятно, знаете, ранние игры в Windows использовали альтернативный метод, где вместо вызова функции блокировки GetMessage они вызывали PeekMessage, а затем вызывали основной цикл обработки игры, если не было обработано никакого сообщения. Различные формы задержек использовались для того, чтобы попытаться получить адекватную частоту кадров без использования 100% CPU. Там не было достаточно хорошего таймера, чтобы обеспечить плавную частоту кадров.

Сегодня нет необходимости явно писать цикл, который вызывает DoEvents. Это может быть возможно теперь получить плавную частоту кадров, используя встроенные таймеры таймера (выставленные в .NET на System.Threading.Timer и завернутые в System.Timers.Timer).

Как я помню, также были проблемы с операциями мыши и клавиатуры. Мы использовали прямой доступ к клавиатуре и мыши, а не в зависимости от цикла сообщения, потому что цикл сообщений часто был слишком медленным и иногда приводил к потере информации.

Я не писал игр в течение нескольких лет, и я не знаю, что такое .NET как игровая платформа. Возможно, что вход по-прежнему является проблемой, - что очередь сообщений просто не достаточно быстра, чтобы дать молниеносную реакцию, которую хотят разработчики игр. Поэтому они обходят очередь сообщений для критических задач.

Answer 2

Все программы, которые работают, никогда не кончаются. Хотя в некоторых случаях вы не взаимодействуете с циклом (например, в веб-программировании или других второстепенных программах)

Ваша ОС представляет собой цикл, ожидающий ввода команд. То же самое с игрой. Веб-сервер представляет собой цикл, ожидающий запросов.

Большое объяснение от пользователя slim on one of my own questions.

Answer 3

Очереди сообщений Бесконечные циклы, а также, что делает все программы, бесконечные циклы.

Answer 4

если вы не чувствуете себя комфортно об этом, пакет его с классом и интерфейсом,

это то, что мы говорим «открыть и закрыть принцип»: открыть интерфейс не изменился, закройте грязную часть.

Почему мы используем цикл? потому что это основная структура нашего компьютера!

Answer 5

Лучшая петля - это бесконечный цикл с блокирующим вызовом для отправки событий/сообщений. Если вам нечего делать, вы действительно не должны спать, а блокировать, ожидая ОС. Но если ОС действительно не блокируется, когда вы проводите опрос на события, спальное время между опросами - единственное решение, предотвращающее 100% использование ЦП.

Answer 6

Я не понимаю, как это можно было бы сделать по-другому?

Выполнение вашей программы происходит внутри потока (или нескольких потоков, если вы хотите). Наличие gameloop (или win32 GetMessage/DispatchMessage pump) - это ожидание события, а затем управление им. Альтернативой будет регистрация обратных вызовов, а затем вызов HandleAllMyMessages(), который внутренне будет делать почти то же самое ... и это на самом деле не купило бы вам ничего.

OS не сможет магически разделить вашу программу на несколько потоков, поскольку она не знает, что вы хотите делать в этих потоках. Истечение нового потока для каждого входящего сообщения было бы как успехом, так и синхронизацией ада.

Answer 7

В Win32 я использую таймер MultiMedia вызвать мой GameLogic тик ...

// request 1ms period for timer 
g_mmTimer = timeBeginPeriod(1); 
if (g_mmTimer != TIMERR_NOERROR) 
    return false; 

//start game loop event timer/thread 
g_mmTimer = timeSetEvent(10, 10, DoUpdate, 0, TIME_PERIODIC); 

При желании, вы можете сделать все чертеж в другом потоке, так что игра логика автоматически не зависит от частоты кадров.

Answer 8

Игры (в большинстве случаев) - это моделирование. Традиционно это означает, что вы обновляете симуляцию, представляете ее текущее состояние (например, визуализируете графику) и повторяете. Естественным представлением для этого является цикл.

С другой стороны, информационный насос Win32 представляет собой специфичную для платформы особенность, ориентированную на приложения, управляемые событиями, которые составляют большинство приложений в Windows. Это ни в коем случае не стандарт для приложений на всех платформах, поэтому неудивительно, что не все программное обеспечение прекрасно вписывается в модель. Поэтому, чтобы изменить типичную программу, подходящую для модели Win32, вы обычно сбрасываете эту очередь за один раз, за ​​одну итерацию цикла, используя PeekMessage, пока она не станет пустой. Или вы помещаете эту логику в отдельный поток и, при необходимости, используете GetMessage.

Для большинства игр с производительностью в виду нет другого практического способа сделать это. Во-первых, если вы попытались сделать игру, управляемую событиями, а не опросом, вам понадобится более высокое разрешение, чем Windows, которое может надежно дать вам, если вы хотите сохранить высокую производительность, на которую играют многие игры. Во-вторых, Windows - это только одна из платформ, на которые написаны игры, и переработка игры, идеально подходящая для модели Win32, будет просто неудобством для выделенных игровых платформ, которые ожидают канонический игровой цикл.

И, наконец, проблемы с «взятием 100% CPU» неуместны. Большинство современных игр предназначены для использования в полноэкранном режиме с эксклюзивным доступом к аппаратным средствам, а не только в одном из нескольких других существующих приложений. Клиенты таких игр на самом деле требуют, чтобы игра максимально использовала их оборудование, и это невозможно сделать, если умышленные вызовы Sleep() или обновления зависят от внешних таймеров, пробуждающих приложение N раз в секунду. Очевидно, что есть исключения для многих игр, например. те, которые предназначены для работы в основном в окне, но важно отметить различие.

Answer 9

MsgWaitForMultipleEvents сочетает в себе функциональность GetMessage/PeekMessage с тайм-аут и способность ждать объектов ядра, например, WaitableTimer.

Я использовал CreateWaitableTimer, чтобы установить желаемую частоту кадров вместе с MsgWaitForMultipleEvents для отправки сообщений с большим успехом для очень гладкой анимации в прошлом, без оживленного ожидания. Я бы хотел, чтобы у других ОС было что-то хорошее.