Новый проект для всех виртуальных пилотов.

[operok]

thread это хорошо, и он там наверняка есть. Но доступ к данным сцены должен быть синхронизирован и тут хоть 100 threads запускай, всё равно только один данные сцены будет апдейтить и при этом thread рендерера не сможет их использовать до окончания апдейта. Я не говорю о приёме пакетов из сети, я говорил об их обработке.

Я не говорил о том что там что-то неправильно, а тем более никого не обвинял в том, что он чего-то незнает или не умеет . Просто, я описал предполагаемую причину фризов. Причём, я указал, что решение не может быть абсолютным и может являться только компромиссом.

Подчеркиваю, это предполагаемая причина, а там всё может быть и по другому

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

Но так никто не делает, все нормальные игроделы применяют такую архитектуру:
есть тред "расчета и отображения картинки на экране"
есть локальный массив параметров в этом треде

есть тред "обмена с сетью"
есть локальный массив параметров в этом треде

тред работы с сетью записывает изменения параметров игры в свой локальный массив параметров, и потом происходит синхронизация массива сетевого треда и масива "отображателя", это процесс происходит для игрока мгновенно (копирование памяти операция быстрая и незаметная по сравнению с остальным). и нигде больше синхронизация не нужна.

[trabla]

Побойся бога трабла! Нет в этом никакой данности. Одно дело, если расшифровка сетевого протокола занимает столько процессорного времени, что ФПС падает. Но когда становятся заметными глазу замирания картинки - это совершенно явная ОШИБКА.

pakman, не о сети я говорил. Читай пост выше .
По моим наблюдениям фриз происходит в моменты, гогда сервер доставляет много информации. Подозреваю, что львиная доля её относится именно к картинке(содержимому 3D сцены). А вносятся изменения в сцену с высшим приоритетом, чем сцена отрисовывается. И поскольку изменений просто много, тои задержка отрисовки начинает зависеть от количества принятых изменений, а не от сети и т.д.
Такое вот моё IMHO.

P.S. ветка, кажется, стала о фризах, а не о новом проекте. Надо, наверное остановиться. Причину, всё равно, знают только разработчики.

[trabla]

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

Я не говорил о том что thread обмена с сетью блокирует thread отрисовки. Я сказал что "внесение изменений в сцену" блокирует отрисовку.

Но так никто не делает, все нормальные игроделы применяют такую архитектуру:
есть тред "расчета и отображения картинки на экране"
есть локальный массив параметров в этом треде

есть тред "обмена с сетью"
есть локальный массив параметров в этом треде

тред работы с сетью записывает изменения параметров игры в свой локальный массив параметров, и потом происходит синхронизация массива сетевого треда и масива "отображателя", это процесс происходит для игрока мгновенно (копирование памяти операция быстрая и незаметная по сравнению с остальным). и нигде больше синхронизация не нужна.

Так делают не только игроделы

[ZOD]

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

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

По моему, что-то тут в вашем объяснении не так, вот мое:
Если у игрока все нормально с приемом, но передачи на сервер нет, то фриз у игрока, а на сервере лаг.
Если все нормально с передачей на сервер, но нет приема, то лагает всех игроков у вас, а на сервере вы летите нормально, фриза нет.

Было у меня вот такое на ГТ1: Лечу, вдруг смотрю все полетели в стороны, глянул на модем, а приема-то нет. Полетал неного, кикнул сервак, в стате диско.
Следующий раз в такой ситуации я просто прыгнул, в стате записали прыгнул.

ПыСы: Пока нашел время написать пост, тут уже столько накатали...

[pakman]

Вы немного не поняли о чём я хотел сказать
Не ожидание "прихода пакета", а ожидание "внесения изменений в сцену" (добавление удаление объектов, подгрузка текстур и т.д). В случае оффлайн, это можно оптимально сделать, поскольку все данные находятся (рассчитываются) на одном компутере. В случае же онлайн часть данных является непредсказуемой и не поддающейся оптимизации, поскольку невозможно предвидеть ни появления ни исчезновения объектов.

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

[Sexton]

А заодно эта идея низводит разработчиков до уровня недоразвитых ламеров. Так что давай отбросим её.
Ожидать опаздавший пакет, что бы верно отобразить опаздавшее событие - абсурд.

Но фризы есть. Пойти чтоли застрелиться?

Отбрасываем.

Что еще может объяснить появление фризов?

[pakman]

P.S. ветка, кажется, стала о фризах, а не о новом проекте. Надо, наверное остановиться. Причину, всё равно, знают только разработчики.

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

[Sexton]

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

Действительно. Процу в онлайне на догфайтах работы доложно быть меньше, но мы наблюдаем фризы и падение ФПС в онлайн.
Чем отличается оффлайн и онлайн? Правильно, наличием работы с сетью во втором случае. Значит собака закопалась именно где-то в работе с сетью.

[Sexton]

Действительно. Процу в онлайне на догфайтах работы доложно быть меньше, но мы наблюдаем фризы и падение ФПС в онлайн.
Чем отличается оффлайн и онлайн? Правильно, наличием работы с сетью во втором случае. Значит собака закопалась именно где-то в работе с сетью.

Все.
Я наконец-то все понял. При работе с сетью закопалась собака. Если мы ее оттуда выкопаем, то фризы и лаги исчезнут!

[trabla]

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

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

[tugarin]

Это просто расстановка приоритетов доступа к ресурсу (данные для рендера). Всё равно их надо изменять с одной стороны и использовать для отрисовки, с другой. Сие, ИМХО, данность и ничего тут не поделаешь

А если сделать грамотно? Вот так например:

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

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

Здесь обозначены только обсуждаемые аспекты, остальное опущено.
Вообще-то это учебник.

Где тут место для 5-10 секундных фризов?
И что тут занимает столько времени? Локирование и отпускание разделяемого ресурса или обновление данных или их считывание? Бред!

[Maximus_G]

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

[tugarin]

Повторяю свое мнение. Фризы картинки введены искусственно для защиты от читеров.

[pakman]

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

С чего ты взял?

[pakman]

Повторяю свое мнение. Фризы картинки введены искусственно для защиты от читеров.

Да здравствует равенство! Теперь мы все читеры!

Считаю твою версию ошибочной.

[tugarin]

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

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

Ответ: потому что в ПХЗСАВН нет первого пункта.

[tugarin]

Да здравствует равенство! Теперь мы все читеры!

Считаю твою версию ошибочной.

Есть какое-нибудь обоснование?

[pakman]

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

Внесены, т.е. уложены на полочки для последующей обсчёта? Да даже если там призойдёт 1000 изменений, подготовка эти данные займёт считанные миллисекунды.

[pakman]

Есть какое-нибудь обоснование?

Я что, должен перед тобой отчитываться? :p Видишь ли, я страшно не люблю использовать набор букв "ИМХО". Но здесь именно такой случай.

[trabla]

А если сделать грамотно? Вот так например:

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

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

Здесь обозначены только обсуждаемые аспекты, остальное опущено.
Вообще-то это учебник.

Где тут место для 5-10 секундных фризов?
И что тут занимает столько времени? Локирование и отпускание разделяемого ресурса или обновление данных или их считывание? Бред!

Я постараюсь не быть столь категоричным

1. (Главный цикл потока приема сетевых данных) Сколько занимает "обновлять данные" и от чего зависит скорость её выполнения? И что включает эта процедура?
2. (Главный цикл потока отрисовки) Сколько занимает времени "считывать данные" и от чего зависит скорость её выполнения? Включает ли оно еще и время для изменения сцены перед рендером? Вот тут я, конечно, не очень разбираюсь, но сильно подозреваю что накладные расходы будут пропорциональны количеству данных от сервера, которые влияют на содержимое сцены.

P.S. tugarin, по-моему мы уже в оффтоп упали. Предлагаю без алгоритмов, "грамотности" учебников и категоричности .

[MUTbKA]

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

Потому что видеокарта все равно одна, а FPS зависит в первую очередь от нее. Нормальный же современный процессор с обсчетом данной конкретной FM на данный момент справляется и один, причем очень уверенно. Поэтому если ты поставишь 2 современных процессора, эффекта не будет. Точнее, будет, только если ты в миссии наставишь туеву хучу техники, но ее должно быть реально МНОГО, причем в РАЗНЫХ местах карты, чтобы не задевать видеокарту.
Пример:
Начинал я летать в ил на версии 1.11, у меня тогда был атлонXP 1600+ (реальная частота 1.4 GHZ, SSE2 нету). В миссии "утопление линкора руделем" у меня при ускорении времени в 8 раз fps сразу же падал капитально (до 3-4), я так понимаю, потому, что процессору приходилось обсчитывать в 8 раз больше физики в единицу времени, и он не справлялся. Через полгода я приобрел P4 2.6Ghz, шина 800, HT, SSE2 и все такое (видеокарта осталась прежней). Первое, что я сделал - это провел вышеприведенный тест, никакого падения fps уже не было.

[tugarin]

Я что, должен перед тобой отчитываться? :p Видишь ли, я страшно не люблю использовать набор букв "ИМХО". Но здесь именно такой случай.

Нет не должен. Но с твой строны было бы любезностью поделиться своим мнением. Я не настаиваю.

[tugarin]

Я постараюсь не быть столь категоричным

1. (Главный цикл потока приема сетевых данных) Сколько занимает "обновлять данные" и от чего зависит скорость её выполнения? И что включает эта процедура?
2. (Главный цикл потока отрисовки) Сколько занимает времени "считывать данные" и от чего зависит скорость её выполнения? Включает ли оно еще и время для изменения сцены перед рендером? Вот тут я, конечно, не очень разбираюсь, но сильно подозреваю что накладные расходы будут пропорциональны количеству данных от сервера, которые влияют на содержимое сцены.

P.S. tugarin, по-моему мы уже в оффтоп упали. Предлагаю без алгоритмов, "грамотности" учебников и категоричности .

Обновление даных и их считывание продразумевает только копирование данных (в идеале memcpy). Внесение любой логики, а тем более каких-либо ожиданий (только подумал об этом и сразу мороз по коже), внутрь пары залочить-разлочить является ГРУБЕЙШИМ ПРОГРАММИСТСКИМ ЛЯПОМ.

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

[trabla]

Обновление даных и их считывание продразумевает только копирование данных (в идеале memcpy). Внесение любой логики, а тем более каких-либо ожиданий (только подумал об этом и сразу мороз по коже), внутрь пары залочить-разлочить является ГРУБЕЙШИМ ПРОГРАММИСТСКИМ ЛЯПОМ.

Ты прав , memcpy - быстрая операция. Но кажется мне, что сервер высылает не готовые данные для сцены, а данные на основании которых вносятся изменения в сцену. Так кто их вычисляет и делает, эти изменения, кто подгружает текстуры для изменённых объектов, меняет их если надо? Или сейчас это уже как-то по другому делается?

[tugarin]

Ты прав , memcpy - быстрая операция. Но кажется мне, что сервер высылает не готовые данные для сцены, а данные на основании которых вносятся изменения в сцену. Так кто их вычисляет и делает, эти изменения, кто подгружает текстуры для изменённых объектов, меняет их если надо? Или сейчас это уже как-то по другому делается?

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

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

Короче, при грамотной архитектуре многопоточной программы, нет места 5-10 секундным фризам из-за синхронизации данных.

Предлагаю считать эту версию фризов тупиковой и больше не возвращаться к ней.

Ну, хотя бы просто поверьте мне! Я этим делом на хлеб себе зарабатываю!