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

[tugarin]

Это был бы оголтелый мутантизм. Не смею даже заподозрить уважаемых разработчиков любимой игры в таких делах.

Смелее, дружище! Я уверен, что замирание картинки производится искусственно. В Ил-2 Штурмовик никаких фризов не было. Там были другие грабли. При отсутствии информации с сервера картинка не замирала, самолет нормально управлялся (кстати, он и сейчас нормально управляется во время фриза, только кратинка замирает). Это приводило к таким ситуациям, что некоторые самолеты противника просто зависали в воздухе. Можно было легко подойти к противнику и расстрелять его зависшего. Я однажды на Геннадиче таким образом расстрелял самолет Лофта. Он тогда еще очень удивился и спросил: "Как ты меня сбил?" Не помню, что я ему ответил, но эта "победа" никакого удовольствия мне не доставила, даже стало немного стыдно.

Лучше бы разработчики вместо замораживания картинки сделали, чтобы на время отсутствия данных от сервера все окружающие самолеты становились невидимыми.

[Sexton]

Прямой связи между фризом и примемом данных с сервера не вижу пока. Часто бывает что связи нет, но и фриза тоже нет.

Может кто-нибудь набереться смелости и напишет письмо разработчикам с простым вопросом "Объясните природу фризов"?

[tugarin]

Прямой связи между фризом и примемом данных с сервера не вижу пока. Часто бывает что связи нет, но и фриза тоже нет.

- Ты суслика видишь?
- Нет.
- И я - нет, а он есть!

[Sexton]

Суслик объясняет многое, но не всё

[Buka]

Кстати, поведение игры очень похоже на поведение Эксплорера. Это хорощо заметно на плохой линии на мопеде. При открытии страницы, если происходит ретрейн, картинка как бы замирает, а потом либо резко прорисовывается, либо выскакивает "Невозможно отобразить страницу" и мы слышим звук набираемого номера.

[pakman]

Кстати, поведение игры очень похоже на поведение Эксплорера. Это хорощо заметно на плохой линии на мопеде. При открытии страницы, если происходит ретрейн, картинка как бы замирает, а потом либо резко прорисовывается, либо выскакивает "Невозможно отобразить страницу" и мы слышим звук набираемого номера.

Бука, гигант! Бросить им в лицо, мол продукт ваш - это те же "Форточки", тока под углом 90°. Это смелый и решительный поступок. Не даром ты у нас в ШАДе курсантский хлеб ел . Подам ходатайство на награждение орденом... мм... себя.

[Buka]

Заедешь, обмоем

[trabla]

Но при чем тут фриз??? Пусть бы его лагала, но почему это должно тормозить МОЮ систему?

Попробую высказать свой взгляд на причину фризов

Это, конечно, можно объяснить, но только при знании архитектуры программы. Могу предположить, что отрисовка картинки синхронизирована с обработкой сообщений от сервера, поскольку информация, которая приходит с сервера, может повлиять на содержание сцены. Так что, если изменения в сцене значительные, например массовые взрывы наземки ( не по твоей вине ) или одновременное открытие огня зенитной артилерией нескольких кораблей, то ничего не будет рисоваться у тебя до тех пор, пока изменения не будут внесены в сцену. С другой стороны, намного выгоднее пересылать одним пакетом (сетевым) как можно больше таких изменений в цену, дабы уменьшить накладные расходы на доставку. Учитывая сказанное выше получается, что если пакет большой, то пока он не будет принят и сцена не будет изменена, отрисовок на экране не будет,Вот вам и фриз

Пример.
Допустим, есть набор команд от сервера, который меняет сцену. Каждая из этих команд имеет свой время выполнения (которое от текущей сложности сцены тоже, кстати, зависит).
Теперь, если приходит пакет в котором n изменений сцены, то можно это обрабатывать двумя способами:

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

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

Судя по наблюдениям, в Иле отдаётся предпочтение первому способу. И, возможно, что "пакетная обработка изменений" позволили поддерживать 128 человек на сервере одновременно.

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

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

[Buka]

По сути ты расширил мой пост на 4 сообщения выше.

[Buka]

ЗЫ Для игры это ИМХО не приемлимо.

[Sexton]

Вот.
Trabla высказал вполне правдоподобную мысль.
Примерно тоже хотел и я сказать.

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

Тогда это может объяснить разное поведение игры при разрыве связи с севером.

[trabla]

ЗЫ Для игры это ИМХО не приемлимо.

Конечно , но там компромисс надо искать, поскольку и плавность отрисовки и скорость обработки данных, пришедших с сервера, есть критические части для онлайна.

[tugarin]

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

Тогда это не архитектура программы, а ляп в архитектуре программы, т.к. все более или менее грамотные разработчики сетевых приложений знают, что сетевой обмен нужно отделять от основной логики программы. Это делается путем выноса логики сетевого обмена в отдельный поток управления (thread). Подобные ляпы допускают только совсем зеленые новички в области создания сетевых приложений. Уверен, что разработчики ПХЗСАВН такого ляпа не допустили. Предположить такое еще хуже, чем то, что боится предположить pakman. Предположить такое - это все равно, что нанести программисту оскорбление.

[Sexton]

Тогда это не архитектура программы, а ляп в архитектуре программы, т.к. все более или менее грамотные разработчики сетевых приложений знают, что сетевой обмен нужно отделять от основной логики программы. Это делается путем выноса логики сетевого обмена в отдельный поток управления (thread). Подобные ляпы допускают только совсем зеленые новички в области создания сетевых приложений. Уверен, что разработчики ПХЗСАВН такого ляпа не допустили.

Почему это именно ляп?

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

[trabla]

Тогда это не архитектура программы, а ляп в архитектуре программы, т.к. все более или менее грамотные разработчики сетевых приложений знают, что сетевой обмен нужно отделять от основной логики программы. Это делается путем выноса логики сетевого обмена в отдельный поток управления (thread). Подобные ляпы допускают только совсем зеленые новички в области создания сетевых приложений. Уверен, что разработчики ПХЗСАВН такого ляпа не допустили.

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

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

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

[tugarin]

Почему это именно ляп?

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

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

[Sexton]

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

Я имел в виду не выделение в отдельный поток отправку и получение данных, а принцип отрисовки сцены.
Я думаю про потоки МГ все же знают, не такие уж они незнайки.

[tugarin]

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

Да, создание архитектуры многопоточной программы - это искусство.
И хорошо владеют этим искусством немногие.
А ошибки синхронизации потоков управления являются одними из самых трудных для отлавливания.

[tugarin]

Я имел в виду не выделение в отдельный поток отправку и получение данных, а принцип отрисовки сцены.
Я думаю про потоки МГ все же знают, не такие уж они незнайки.

Ты ерунду пишешь. Каждый разработчик сетевого приложения ОБЯЗАН предполагать, что данные по сети могут прийти с какой угодно задержкой или не прийти вовсе. В данном случае откладывание отрисовки и ожидание прихода полного набора некоторых данных без приемлемого таймаута есть ГЛУПОСТЬ!

[trabla]

Да, создание архитектуры многопоточной программы - это искусство.
И хорошо владеют этим искусством немногие.
А ошибки синхронизации потоков управления являются одними из самых трудных для отлавливания.

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

[Sexton]

Ты ерунду пишешь. Каждый разработчик сетевого приложения ОБЯЗАН предполагать, что данные по сети могут прийти с какой угодно задержкой или не прийти вовсе. В данном случае откладывание отрисовки и ожидание прихода полного набора некоторых данных без приемлемого таймаута есть ГЛУПОСТЬ!

Не факт.

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

[pakman]

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

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

[trabla]

Не факт.

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

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

[tugarin]

Не факт.

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

Проблема в том, что это объяснение одновременно ставит по сомнение компетентность разработчиков, а ведь мы этого всячески избегаем, не так ли?

[pakman]

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

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

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