Эта проблема с задержкой реагирования связана с практически всеми контроллерами движения, такими как Hydra, Wii Remote, Kinect или PlayStation Move.
Проблема заключается в следующем:
Когда поступает входной поток, вы принимаете решение покадрово о том, следует ли доверять входным данным; будут ли тенденции, которые вы видите сейчас, продолжаться в данных, которые вы получите через дюжину миллисекунд. Например, если в этом кадре произошел внезапный сдвиг вправо, вы не знаете, является ли это реальным битом входных данных (и поэтому вы должны воздействовать на него), или это просто джиттер (и поэтому вы должны его игнорировать). Что бы вы ни выбрали, если позже вы обнаружите, что ошиблись, вы либо позволили входному джиттеру войти в вашу игру (в первом случае), либо добавили лаг (в последнем случае).
Нет хорошего решения для этого. «Правильное» решение для определения того, является ли ввод действительным или дрожанием, требует знания того, что будет делать входной поток в будущем, а также того, что он делал в прошлом. Мы не можем сделать это в играх по понятным причинам. Так что нет, нет способа отфильтровать данные вращения, чтобы устранить джиттер без потери точности, в контексте игры, которая работает с входными данными в режиме реального времени.
Я видел, как крупный производитель рекомендовал разработчикам справиться с этой проблемой, заставляя игроков удерживать кнопку во время вращения элемента управления, чтобы в этот момент игра могла отключить свой код защиты от джиттера, чтобы он не отставал. (Я не рекомендую это, но это один из подходов).
Я видел несколько библиотек промежуточного программного обеспечения для ввода движения, которые решают эту проблему, вводя искусственную задержку ввода - есть буфер в четверть секунды, в который вводятся входные данные, и ваша игра слышит только о входе через четверть секунды, так что библиотека может сгладить дрожание для вас, зная, что происходит до и после «настоящего» с точки зрения игры. Это прекрасно работает, кроме четверти секунды задержки во всем. Но это один из способов решения проблемы, и он может выполнять потрясающую работу по точному представлению движения с удаленным джиттером за счет постоянного лага.
Но, не вдаваясь в эту крайность, мы все еще можем сделать что-то, чтобы значительно улучшить поведение, хотя мы знаем, что всегда будут «наихудшие сценарии», которые ведут себя неидеально.
Основная идея заключается в том, что мы действительно заботимся о джиттере, когда контроллер в основном неподвижен, и мы действительно заботимся о задержке, когда контроллер перемещается. Поэтому наша стратегия должна заключаться в том, чтобы попытаться справиться с такими вещами, чтобы у нас было отставание, когда контроллер находится в неподвижном состоянии, и дрожание, когда контроллер находится в движении.
Вот два возможных способа сделать это:
Одним из распространенных подходов является «заблокированная / разблокированная» система, в которой вы отслеживаете ориентацию устройства, и если она не меняется в течение короткого времени (полсекунды или около того), вы «блокируете» эту ориентацию, не предпринимая никаких действий. действие, основанное на заявленной ориентации устройства, до тех пор, пока оно не станет достаточно отличным для повторной разблокировки. Это может полностью подавить дрожание, основанное на ориентации, без введения задержки, когда ориентация активно меняется. Может быть, намек на задержку, прежде чем код решит, что ему нужно переключиться в «разблокированный» режим, но это будет намного лучше, чем иметь лаг везде.
Другой подход заключается в усреднении входных данных из кадров. Важным моментом здесь является усреднение только входных данных из фреймов, в которых входные данные были примерно одинаковыми. Это означало, что небольшие дрожания будут размываться и смягчаться, но большие изменения не размываются, потому что их данные не достаточно похож на данные из предыдущих кадров.
Есть и другие способы получить подобный эффект. Основная идея заключается в том, что в игре в реальном времени нельзя одновременно использовать джиттер и лаг, потому что для этого потребуются знания о будущем. Таким образом, вам нужно выбрать, когда смещать поведение вашего элемента управления к принятию джиттера, а когда - к смещению в сторону принятия лага, чтобы сделать общее восприятие как можно более неплохим.