Понимание DIP для движения / скорости спрайта

Question

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

Я пишу игру, основанную на Surfaceview, и пока все идет хорошо, однако я хочу переместить мой основной спрайт, например, на 1 пиксель на экране 160DPI в качестве базовой линии (так что в основном 1 DIP как 1 пиксель = 1 DIP на экране 160DPI правильно?)

Я использую следующие форумы:

private static final float spritemovestep = 1f;
final float scale = getResources().getDisplayMetrics().density;
MoveX = (int) (spritemovestep * scale + 0.5f);

А потом ... что-то вроде

SpriteX=SpriteX+MoveX

Первый вопрос - это правильно?

Если это так, может кто-нибудь объяснить, для чего на самом деле + .05f, я читал, что он «округляется до ближайшего числа», но ....

если spritemovestep = 1, то на экране с разрешением 120 точек на дюйм (который возвращает 0,75 в качестве шкалы, я думаю) это будет работать как: 1 x .75 + .5? что будет 1,25? Так для чего же .5?

Кроме того, каков результат, если он приведен к значению int?

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

Также некоторые спрайты, которые должны двигаться с разной скоростью, движутся с одинаковой скоростью с определенной плотностью.

Я уверен, что я глупый и что-то здесь упускаю, но я просто не могу понять, как это должно работать. Если я хочу переместить мой спрайт на 1 DIP / физический пиксель на экране MDPI, как он может перемещаться менее чем на 1 пиксель на экране LDPI?

Кроме того, что это за формула, которую я продолжаю видеть:

px = dp * (dpi / 160) - When is this used?

Буду очень признателен, если кто-нибудь ответит на мои вопросы.

Спасибо всем

Answer 1

+ 0,5f - округлить до ближайшего нукбера, как вы сказали. В идеале, когда число уменьшается для ldpi, значение 1 становится 0,75, что при приведении к int выражается как меньше 1 или ~ = 0. При добавлении округляющего числа это число увеличивается до 1,25, которое при приведении к int дает <2 или ~ = 1. Таким образом, ваш спрайт должен быть нарисован с минимальным движением 1. Единственная причина, по которой спрайты, которые движутся с разными скоростями, будут двигаться с одинаковыми скоростями, это если они настолько близки, что при округлении они получаются одинакового размера с использованием шкалы. ты дал. В целом, ваше уравнение очень похоже на другие, которые я видел. Я создаю игру, которая использует SurfaceView для компании, в которой я работаю, и, хотя я не могу вдаваться в детали кода, ваша проблема - та, с которой я боролся в течение некоторого времени. Я не уверен, как обновляется ваша физика, но, возможно, это то, что вы должны проверить, в частности, как он учитывает такты для вашего игрового таймера. Может случиться так, что ваше приложение считывает свои тики как слишком близко друг к другу, чтобы достичь точки, где оно достигнет точки перемещения 1.25 или 1 после приведения к int, и, следовательно, ваш спрайт не движется. Я кратко испытал эту проблему и сначала смотрел на свою скорость, пока не обнаружил, что ошибка была в таймере. Еще одна вещь, которую я заметил, это то, что ваш алгоритм собирает плотность. На устройстве mdpi это возвращает 1 или 160? Это могло иметь большое значение, но я не уверен, поскольку уравнение, которое я использовал, было другим. Другое уравнение, которое вы нашли, является перефразировкой уравнения, перечисленного в руководстве по разработке на android.developer.com, чтобы описать, как ОС преобразует пиксели в провал. Резонансные люди, как правило, цитируют это, чтобы предоставить ссылку, чтобы помочь другим создать собственный алгоритм масштабирования, соответствующий потребностям их приложения. Надеюсь, это поможет, так как это действительно лучший ответ, который я могу дать на данный момент. Извините за любые опечатки, я отправляю это с моего телефона </p>