Материал наглый мусор и лютый обман!!! Я бы таких авторов к клавиатуре не подпускал бы.
1. Вне зависимости какая у вас максимальная частота обновления экрана, высокий FPS это уменьшение обработки и реагирования на ваш ввод со стороны девайсов. Повышая FPS на кратные уровни выше вашей герцовки, вы не только получите более быстрое реагирование на команды ввода, но и существенно увеличите плавность вашего геймлея без увеличения частоты обновления экрана, так как задержка это не только показатели пинга и частоты обновления.
2. «Итог такой: большая герцовка позволяет лучше раскрыть уже имеющиеся навыки игры» Создатель, теперь они и навыки раскрывают. Большая герцовка даёт лишь наглядное отображение на мониторе кадров, которые были подготовлены видеокартой и процессором. Из-за большой скорости обновления экрана обеспечивается более плавная картинка и о ужас, в отличие от вашего бреда, более быстрое отображение появления противника.
PS. Я люблю ixbt, но некоторые авторы просто постят лютый бред ради просмотров.
Если его готовят западные снежинки, то лучше не надо. Опять, вместо приличный драмы, будет история о «не такой как все» цветной вампирше, которая никак не может определиться: вампир она или чупакабра бесполое. Материал хороший.
Сегодняшний Web построен на протоколе TCP, который был выбран за его надёжность и гарантированность доставки пакетов. Для открытия TCP-соединения используется так называемое «трёхкратное рукопожатие». Это означает дополнительные циклы отправки-приёма сообщений для каждого нового соединения, что увеличивает задержки.
Протокол UDP, с другой стороны, построен на идее «отправить пакет и забыть о нём». Сообщение, отправленное по UDP, будет доставлено получателю (не гарантированно, с некоторой вероятностью успеха). Яркое преимущество здесь в меньшем времени установки соединения, такой же яркий недостаток — негарантированность доставки или порядка прихода пакетов получателю. Это означает, что для обеспечения надёжности придётся построить некоторый механизм поверх UDP, который гарантирует доставку пакетов.
Зачем нужен QUIC?
Планы команды разработчиков протокола QUIC выглядят очень амбициозно: протокол попытается совместить скорость UDP с надёжностью TCP.
Вот что об этом пишет Википедия:
Улучшение протокола TCP является долговременной целью для Google, а протокол QUIC создан как эквивалент независимого TCP-соединения, но с уменьшенными задержками и улучшенной в духе SPDY поддержкой мультиплексирования. Если QUIC покажет свою эффективность, то эти возможности могут войти в следующую версию протоколов TCP и TLS (разработка которых занимает больше времени).
В этой цитате есть важный момент: если QUIC докажет свою эффективность, то есть шанс, что опробованные в нём идеи станут частью следующей версии TCP.
Протокол TCP достаточно сильно формализован. Его реализации есть в ядрах Windows и Linux, в каждой мобильной OS, да и во многих более простых устройствах. Улучшение TCP является непростым делом, поскольку все эти реализации должны его поддерживать.
UDP же является относительно простым протоколом. Значительно быстрее разработать новый протокол поверх UDP чтобы иметь возможность проверить теоретические идеи, работу в перегруженных сетях, обработку заблокированных потерянным пакетом потоков и т.д. Как только эти моменты будут прояснены — можно будет начинать работу по переносу лучших частей QUIC в следующую версию TCP.
Второй больно трешовых,
Третий для любителей быстрых зомби.
Четвёртый фильм это шедевр.
Пятый фильм адовый трешь.
1. Вне зависимости какая у вас максимальная частота обновления экрана, высокий FPS это уменьшение обработки и реагирования на ваш ввод со стороны девайсов. Повышая FPS на кратные уровни выше вашей герцовки, вы не только получите более быстрое реагирование на команды ввода, но и существенно увеличите плавность вашего геймлея без увеличения частоты обновления экрана, так как задержка это не только показатели пинга и частоты обновления.
2. «Итог такой: большая герцовка позволяет лучше раскрыть уже имеющиеся навыки игры» Создатель, теперь они и навыки раскрывают. Большая герцовка даёт лишь наглядное отображение на мониторе кадров, которые были подготовлены видеокартой и процессором. Из-за большой скорости обновления экрана обеспечивается более плавная картинка и о ужас, в отличие от вашего бреда, более быстрое отображение появления противника.
PS. Я люблю ixbt, но некоторые авторы просто постят лютый бред ради просмотров.
Протокол UDP, с другой стороны, построен на идее «отправить пакет и забыть о нём». Сообщение, отправленное по UDP, будет доставлено получателю (не гарантированно, с некоторой вероятностью успеха). Яркое преимущество здесь в меньшем времени установки соединения, такой же яркий недостаток — негарантированность доставки или порядка прихода пакетов получателю. Это означает, что для обеспечения надёжности придётся построить некоторый механизм поверх UDP, который гарантирует доставку пакетов.
Зачем нужен QUIC?
Планы команды разработчиков протокола QUIC выглядят очень амбициозно: протокол попытается совместить скорость UDP с надёжностью TCP.
Вот что об этом пишет Википедия:
Улучшение протокола TCP является долговременной целью для Google, а протокол QUIC создан как эквивалент независимого TCP-соединения, но с уменьшенными задержками и улучшенной в духе SPDY поддержкой мультиплексирования. Если QUIC покажет свою эффективность, то эти возможности могут войти в следующую версию протоколов TCP и TLS (разработка которых занимает больше времени).
В этой цитате есть важный момент: если QUIC докажет свою эффективность, то есть шанс, что опробованные в нём идеи станут частью следующей версии TCP.
Протокол TCP достаточно сильно формализован. Его реализации есть в ядрах Windows и Linux, в каждой мобильной OS, да и во многих более простых устройствах. Улучшение TCP является непростым делом, поскольку все эти реализации должны его поддерживать.
UDP же является относительно простым протоколом. Значительно быстрее разработать новый протокол поверх UDP чтобы иметь возможность проверить теоретические идеи, работу в перегруженных сетях, обработку заблокированных потерянным пакетом потоков и т.д. Как только эти моменты будут прояснены — можно будет начинать работу по переносу лучших частей QUIC в следующую версию TCP.