Войти
ПрограммированиеФорумОбщее

Многопоточность в игровом движке (2 стр)

Страницы: 1 2
#15
12:45, 15 мар. 2019

Tiendil
> У графония свой объект с координатами и данными графики. Логика шлёт графонию
> команду "меняй координаты своего объекта в такие с такой-то скоростью" графоний
> и меняет по кадрам с учётом скорости рендера.

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

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


#16
(Правка: 13:28) 13:20, 15 мар. 2019
И в результате игрок на экране будет видеть совсем не то что происходит в логике - потому что графоний еще рисует старые координаты, а логика уже давно подсчитала новые

Это норм.

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

Это так во всем мире и работает. Аналогичная херня с сетевым лагом и лаг предикшоном. Решается разработчиками путем "пусть эти нищеброды покупают себе новые пеки и проводят нормальный интернет".

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

Или левел-дизайнерам на консолях намекает "урезать осетра и прочие хотелки"

Хреновый это подход.

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

#17
14:51, 15 мар. 2019

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

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

Страницы: 1 2
ПрограммированиеФорумОбщее