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

Архитектура передачи игровых данных между двумя потоками (2 стр)

Страницы: 1 2
#15
19:40, 8 авг. 2016

RadianTOR

ну 120 фпс обычно и не достигают, 60-то с трудом. Тупо пропускают и не рендерят


#16
20:32, 8 авг. 2016

clc
> 120 фпс
Это был утрированный пример.
> 60-то с трудом
Всмысле? Откуда такой порог?

#17
1:30, 9 авг. 2016

Это самая обыкновенная задача движка.
Неспроста же в метод обновления приходит время, прошедшее между кадрами.

Автор не указал, на каком языке пишет свое решение.
Например, на C# в движке cocossharp https://github.com/mono/CocosSharp реализован сбор неких объектов RenderCommand со всех объектов, которые имеют отрисовку.
Всякий раз, когда объект уходит из отрисовки, то он вызывает перестроение списка команд. Перестроение команд делает метод Update.
Метод Draw идет по этим командам и рендерит вершины с необходимыми свойствами. Метод Update аналогично идет по всем подписчикам сцены.
Потоки разные и не пересекаются. Если не ошибаюсь, они уже разные еще на этапе monogame движка, на котором основан cocossharp.

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

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

#18
2:56, 9 авг. 2016

L1f
> а. Выделить отдельную систему для хранения данных, куда апдейт будет записывать
> данные, а рендер считывать.
Примерно это и делать. Нужно отделить данные от рендера. Рендер объекты должны иметь указатель на данные. Тогда апдейт будет заключатся просто в атомарной подмене этих указателей. Ну и дальше в момент рендера проверяешь, менялись данные - значит обновляем буфера/текстуры.

#19
3:05, 9 авг. 2016

MrShoor
> Примерно это и делать. Нужно отделить данные от рендера. Рендер объекты должны
> иметь указатель на данные. Тогда апдейт будет заключатся просто в атомарной
> подмене этих указателей. Ну и дальше в момент рендера проверяешь, менялись
> данные - значит обновляем буфера/текстуры.
Data Oriented программирование? Например, под соусом классического ECS?
Там, насколько мне известно, чётко проведена грань:
Entity - контейнер данных
Component - данные
System - обработчик данных

#20
3:23, 9 авг. 2016

Laynos
> Data Oriented программирование?
Нет. Data Oriented - это про то, как лучше данные организовать под кеш и т.п. А я про то - как проще разруливать синхронизацию апдейта мира и рендера. И проще всего - подменить указатель на данные, а рендер сам пусть разбирается что куда обновлять.

#21
16:27, 12 авг. 2016

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

#22
0:35, 13 авг. 2016

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

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

#23
0:40, 13 авг. 2016

Zab
> Винда оптимизирована для офис-приложений, а вовсе не для игр.
Стесняюсь спросить, а какая ОС оптимизировна для игр, и может стать на десктоп?

#24
1:04, 13 авг. 2016

MrShoor
> Стесняюсь спросить, а какая ОС оптимизировна для игр, и может стать на десктоп?
Можно подумать, выбирать кто-то предлагает... У потенциального юзера если винда - значит будешь писать игры под винду. Если она что-то делает плохо - выкручиваешься как можешь.

По идее, для условий динамичных игр, с хорошим фпс, нужна система реального времени, каковой не является ни винда, ни все популярные версии юникса. Писать игры под QNX я не предлагаю, ибо игроков не найдешь ;)

Типичная проблема: сделал ты у себя все что мог, надо подождать. Знаешь что в системе не один, отдаешь управление. В системах реального времени есть возможность системе объяснить когда тебе надо управление обратно, ни в винде, ни в юникса такой возможности нет. Система сама решает когда тебе выделить следующий квант, и она старается выделять кванты пореже, но делать их побольше, ибо так достигается большая производительность.

Вот и крутят все подряд холостые циклы. Отдашь управление - обратно не получишь вовремя. А потом жалуемся что ресурсов в системе ни на что не хватает. Холостые циклы крутят даже драйвера.

#25
10:33, 13 авг. 2016

Zab
> Вот и крутят все подряд холостые циклы
> Холостые циклы крутят даже драйвера.
Попахивает хвостиками.

#26
17:32, 13 авг. 2016

Интерполяция для связных объектов не будет работать, если делать ее без учета связей.
В рендере просто нужно дождаться завершения апдейта, а в апдейте - завершения рендера. И успешно попасть в RC.

#27
15:29, 24 авг. 2016

https://software.intel.com/ru-ru/articles/designing-the-framework… l-game-engine
Здесь все написано

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

Тема в архиве.