DirectX: Игровой порядок цикла, потяните сначала и затем обработайте вход?
Я просто прочитывал документацию DirectX и встретился с чем-то интересным на странице для IDirect3DDevice9:: BeginScene:
Для включения максимального параллелизма между ЦП и графическим акселератором выгодно назвать IDirect3DDevice9:: EndScene максимально далеко впереди вызова, существующего.
Я был приучен к записи моего игрового цикла для обработки входа и такого, затем тяну. У меня есть он назад? Возможно, игровой цикл должен больше быть похожим на это: (полупсевдокод, очевидно)
while(running) {
d3ddev->Clear(...);
d3ddev->BeginScene();
// draw things
d3ddev->EndScene();
// handle input
// do any other processing
// play sounds, etc.
d3ddev->Present(NULL, NULL, NULL, NULL);
}
Согласно тому предложению документации, этот цикл "включил бы максимальный параллелизм".
Это обычно делается? Там какие-либо оборотные стороны к упорядочиванию игрового цикла как это? Я не вижу настоящей проблемы с ним после первого повторения... И я знаю лучший способ знать, что увеличение действительной скорости чего-то вроде этого должно на самом деле сравнить его, но кто-либо еще уже попробовал это, и можно ли засвидетельствовать какое-либо увеличение действительной скорости?
3 ответа
Поскольку я всегда чувствовал, что рисовать перед симуляцией было «неудобно», я старался откладывать розыгрыши до момента обновления, но также и после " настоящий "звонок. Например.
while True:
Simulate()
FlipBuffers()
Render()
В то время как в первом кадре вы ничего не переворачиваете (и вам нужно настроить все так, чтобы первое переворачивание действительно переходило в известное состояние), это всегда казалось мне немного лучше, чем помещать сначала Render () , даже если порядок действий в пути остается прежним.
Короткий ответ - да, это обычно так. Взгляните на следующую презентацию игрового цикла в God of War III на PS3:
http://www.tilander.org/aurora/comp/gdc2009_Tilander_Filippov_SPU.pdf
Если у вас двойная игра с буферизацией при 30 кадрах в секунду, задержка ввода будет 1/30 ~ = 0,033 секунды, что слишком мало для обнаружения человеком (для сравнения, любое время реакции менее 0,1 секунды на 100 метров считается ложным запуском) .
Стоит отметить, что почти на всех аппаратных средствах ПК BeginScene и EndScene ничего не делают. На самом деле драйвер буферизирует все команды рисования, а затем, когда вы вызываете present, он может даже не начать рисовать. Обычно они буферизируют несколько кадров команд рисования, чтобы сгладить частоту кадров. Обычно драйвер выполняет действия, основанные на вызове present.
Это может вызвать задержку ввода, если частота кадров не особенно высока.
Я бы сказал, что если бы вы выполняли рендеринг непосредственно перед вызовом present, вы бы не заметили никакой разницы с приведенным выше циклом. Конечно, на некоторых странных аппаратных средствах это может вызвать проблемы, поэтому, в общем, лучше всего использовать цикл, как вы предлагаете выше.