Войти
ПрограммированиеФорумСеть

Объясните на пальцах тыры пыры девять десять - как правильно синхронизировать передвижение. (4 стр)

Страницы: 13 4 5 69 Следующая »
#45
22:39, 20 сен. 2015

tumblerr
> Но это уже будет не частота получения данных, это интервал получения данных
Для тех, кто не учился в школе, частота и интервал (т.е. период) связаны формулой x = 1/y. В некотором смысле, частота и интервал это одно и то же.

> Это значит, что за одну и туже единицу времени, клиент с меньшим лагом получит
> больше сообщений об изменении мира
Нет! Блин, я даже картинку тебе нарисую.

+ Показать

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


#46
22:42, 20 сен. 2015

tumblerr
> поэтому пытаемся как-то помочь немного усредняя
Это ты работаешь над чем-то? Или так, диванная теория?

Вот, даже так нарисую. Шо так три обновления в секунду, шо так. Независимо от пинга.
Изображение

#47
23:07, 20 сен. 2015

-Eugene-
> Вот хоть убей, не вижу, где они различаются.
Конечно не увидишь. Фигню же нарисовал.
Теперь выделим первые 2 сообщения от первого клиента.
И увидно, что за это время, второй клиент получит только одно сообщения.
А если придираться к рисунку, то за время пока первый получит 2 сообщения, второй вообще ни одного.
Изображение

#48
23:20, 20 сен. 2015

tumblerr
> Фигню же нарисовал.
Я нарисовал простую как столб схему рассылки обновлений. Если ты знаешь другую...

> Теперь выделим первые 2 сообщения от первого клиента
Нашел блин, к чему придраться.
Первую секунду игровой сессии можно оставить на нужды синхронизации. Какая разница, что там потерялось?
Этого все равно никто не заметит, это вообще может происходить на этапе загрузки. Начиная со второй секунды оба клиента получают ОДИНАКОВОЕ число обновлений.

#49
23:46, 20 сен. 2015

-Eugene-
> Я нарисовал простую как столб схему рассылки обновлений.
Вопроса что ты нарисовал нет. Вопрос в том как ты нарисовал. А нарисовал ты некорректно.

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

-Eugene-
> Начиная со второй секунды оба клиента получают ОДИНАКОВОЕ число обновлений.
Ну так это очевидно, что все клиенты получают всегда одинаковое число сообщений.
Если конечно специально не ломать логику отправки.
Фишка в том, что лагающий клиент получает их с задержкой.
И получается, что нормальный клиент получает 3 сообщ/сек, а лагающий получает 1 сообщ/сек.
Каждую следующую секунду ничего не меняется. 
На твоем же рисунке все выглядит так, будто клиент может получить новое сообщение, в процессе получения старого.
А это невозможно. Сообщения приходят по очереди. Да, есть случаи когда, очередность нарушается.
Но сам принцип очереди от этого не меняется.
Каждая новая стрелка должна начинаться с окончания предыдущей, тогда рисунок будет корректным.
Изображение

#50
23:55, 20 сен. 2015

tumblerr
> Что это за мифические нужды синхронизации такие, можешь объяснить?
Подождать секунду после загрузки, чтобы накопить сведения о мире.

> На твоем же рисунке все выглядит так, будто клиент может получить новое
> сообщение, в процессе получения старого.
> А это невозможно. Сообщения приходят по очереди
Они и приходят по очереди на моем рисунке. Одно за другим.
Получение сообщения - это конец стрелки.
А сама стрелка - это то, как оно физически идет от сервера к клиенту. То есть задержка на доставку, тот самый лаг.

#51
23:56, 20 сен. 2015

-Eugene-
> Получение сообщения - это конец стрелки.
На твоей картинке для первого клиента так и есть.
А вот второй клиент начинает получать новое сообщение еще в процессе получения старого.

#52
0:14, 21 сен. 2015

tumblerr
> Ну так это очевидно, что все клиенты получают всегда одинаковое число
> сообщений.
> Если конечно специально не ломать логику отправки.

> Каждая новая стрелка должна начинаться с окончания предыдущей, тогда рисунок
> будет корректным.
зачем логику отправки поменял? совсем упоролся? : )

#53
0:35, 21 сен. 2015

Sh.Tac.
> зачем логику отправки поменял? совсем упоролся? : )
Сам ты упоролся, где изменена логика отправки?
Сообщения по прежнему отправляются по очереди.

#54
0:41, 21 сен. 2015

tumblerr
> На твоей картинке для первого клиента так и есть.
> А вот второй клиент начинает получать новое сообщение еще в процессе получения
> старого.
Ещё раз. Получение сообщения это ТОЧКА на прямой. Все точки для всех сообщений для обоих клиентов строго последовательны. Каждый клиент получает сообщения по-очереди

> Сам ты упоролся, где изменена логика отправки?
> Сообщения по прежнему отправляются по очереди.
Он имеет в виду, что ты изменил частоту отправки сообщений с сервера. А её менять нельзя по условию задачи.

#55
1:16, 21 сен. 2015

-Eugene-
> Получение сообщения это ТОЧКА на прямой.
Во первых, где там на картинке нарисована хоть одна точка на любой прямой?
А во вторых, расскажите, как вы меняете законы физики этого мира для своих игр,
что у вас получение сообщения становится одномоментной операцией, не растянутой во времени.

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

Вы вообще понимаете о чем говорите? Вы утверждаете, что если пренебречь волшебной "начальной синхронизацией",
то разницы между клиентом с лагом в 10мс и клиентом с лагом в 1000мс нет, а это лютый бред.

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

И ваше это словоблудие, с кривыми картинками притянутыми за уши, ничего не изменит)))

#56
3:18, 21 сен. 2015

Я предлагаю устроить бой на уровне исходников движог unity3d + сокеты а не unet.
Чтобы не было лишней трэшатины типа winapi с++ указатели аллокаторы gc и пр на прямую не относящейся к достижению цели понимания.

#57
3:50, 21 сен. 2015

Едрить вы тут развели. Вот нет что бы просто прочитать любую статью о работе клиент-сервер?

#58
4:08, 21 сен. 2015

tumblerr
> лагающий клиент всегда будет получать старые данные, на величину задержки
Да, что и отражает картинка, которую заботливо нарисовал -Eugene-

А вот твоя картинка, ровно как и заявления про частоту — чушь. Не нужно дожидаться, когда сообщение дойдёт до получателя, чтобы отправить следующее.
Сообщения — это непрерывный бесконечный поезд, который едет со станции Сервер к станциям Клиент1 и Клиент2.
Клиент2 просто находится дальше, поэтому к нему конкретный вагон приедет позже, но частота, с которой вагоны мимо него проносятся такая же.

#59
8:45, 21 сен. 2015

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

Страницы: 13 4 5 69 Следующая »
ПрограммированиеФорумСеть

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