了解精灵运动/速度的 DIP
这是我的第一篇文章，所以如果我在提问时做错了什么，我提前道歉。我在网上寻找了一个具体的答案，但找不到一个，所以这里......
我正在编写一个基于 Surfaceview 的游戏，到目前为止，一切进展顺利，但是，我想要例如，将我的主精灵在 160DPI 屏幕上移动 1 个像素作为基线（所以基本上 1 DIP 作为 1 像素 = 160DPI 屏幕上的 1 DIP，正确吗？）
我正在使用以下论坛：
private static final float spritemovestep = 1f;
final float scale = getResources().getDisplayMetrics().density;
MoveX = (int) (spritemovestep * scale + 0.5f);
然后...类似于
SpriteX=SpriteX+MoveX
第一个问题- 这是正确的吗？
如果是，有人可以解释一下 +.05f 的实际用途吗？我读过它是“四舍五入到最接近的数字”但是......
如果 spritemovestep = 1，则在 120DPI 屏幕上（返回 .我认为 75 作为比例）它会计算为：1 x .75 + .5？哪个是 1.25？那么 .5 是做什么用的呢？
另外，当它转换为 int 值时，结果是什么？
在某些情况下，最终结果在低密度屏幕上似乎为“0”，因此精灵根本不移动。
此外，一些本应以不同速度移动的精灵在某些密度下以相同的速度移动。
我确信我很愚蠢并且在这里遗漏了一些东西，但我只是不明白这是如何工作的。如果我想在 MDPI 屏幕上将精灵移动 1 个 DIP/物理像素，它在 LDPI 屏幕上如何移动少于 1 个像素？
另外，我一直看到的这个公式是什么：
px = dp * (dpi / 160) - When is this used?
如果有人能回答我的问题，我将非常感激。
谢谢大家
This is my first post, so I apologise in advance if I have done anything wrong here in asking my question. I've looked all over the net for a specific answer, but can't find one, so here goes.....
I'm writing a game based on Surfaceview and so far, all is going well, however, I want to move my main sprite for example by 1 pixel on a 160DPI screen as a baseline (so basically 1 DIP as 1 pixel = 1 DIP on a 160DPI screen correct?)
I'm using the using the following forumla:
private static final float spritemovestep = 1f;
final float scale = getResources().getDisplayMetrics().density;
MoveX = (int) (spritemovestep * scale + 0.5f);
And then... something like
SpriteX=SpriteX+MoveX
First question - is this correct?
If it is, can someone explain what the +.05f is actually for, I've read that it's to 'round up to the nearest number' but....
if spritemovestep = 1, then on a 120DPI screen (which returns .75 as the scale I think) it would work out as: 1 x .75 + .5? which would be 1.25? So what is the .5 for?
Also what is the result when it's cast to an int value?
On some, the final result seems to be '0' on a low density screen so the sprite isn't moving at all.
Also some sprites which are supposed to be moving at different speed are moving at the same speed at certain densities.
I'm sure I'm being silly and missing something here but I just can't understand how this is supposed to work. If I want to move my sprite by 1 DIP/physical pixel on a MDPI screen how can it move less than 1 pixel on a LDPI screen?
Also, what is this formula I keep seeing:
px = dp * (dpi / 160) - When is this used?
Would really appreciate if someone could answer my questions.
Thanks all
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正如您所说，+0.5f 是四舍五入到最接近的数字。理想情况下，当 ldpi 的数字按比例缩小时，值 1 变为 0.75，当转换为 int 时，该值表示为小于 1 或 ~=0。通过添加舍入数字，该数字提高到 1.25，当转换为 int 时，会产生 <2 或 ~=1。这样，您的精灵应该以最小移动 1 进行绘制。以不同速度移动的精灵会以相同的速度移动的唯一原因是，如果它们太接近，以至于在舍入时，使用比例尺它们最终会具有相同的大小你给了。总而言之，你的方程与我见过的其他方程非常相似。我正在为我工作的公司制作一款使用 SurfaceView 的游戏，虽然我无法详细说明代码，但你的问题是我一段时间以来一直困扰的问题。我不确定你的物理如何更新，但也许这是你应该检查的事情，特别是它如何计算游戏计时器的滴答声。您的应用程序可能会读取其刻度，因为它们之间的距离太近，无法达到在转换为 int 后移动 1.25 或 1 的点，因此您的精灵看起来不会移动。我短暂地遇到了这个问题，首先查看我的速度，直到我发现错误出在计时器中。我注意到的另一件事是你的算法收集密度。在 mdpi 设备上，返回 1 还是 160？这可能会产生很大的影响，但我不确定，因为我使用的方程不同。您找到的另一个方程是 android.developer.com 开发指南中列出的方程的释义，用于描述操作系统如何将像素转换为倾角。人们倾向于引用的原因是提供参考，以帮助其他人构建自己的算法，以适合其应用程序的需求。希望这会有所帮助，因为这确实是我目前能给出的最佳答案。抱歉，有任何打字错误，我是通过手机发送的
The +0.5f is to round up to the nearest nukber, as you said. Ideally, when the number is scaled down for ldpi, a value of 1 becomes 0.75, which, when cast to an int is expressed as less than 1 or ~=0. By adding the rounding figure, this number is raised to 1.25 which, when cast as an int yields <2 or ~=1. This way, your sprite should be drawn with a minimum movement of 1. The only reason sprites that move at different speeds would move the same speeds is if they are so close that, when rounded, they wind up being the same size using the scale you gave. Altogether, your equation is very similar to others ive seen. Im making a game that uses surfaceview for the company i work for as well, and while i cant go into details on the code, your issue is one that i struggled with for sone time. Im not sure how your physics updates, but perhaps thats something you should check into, specifically, how it counts ticks for your game timer. It may be that your application is reading its ticks as being too close together to reach the point where it would hit the point of moving the 1.25 or 1 after casting to int, and therefore your sprite appears not to move. I briefly experienced that problem and at first was looking at my velocity until i found that the error was in the timer. One other thing i noticed is that your algorithm collects the density. On a mdpi device, does this return 1 or 160? That could make a big difference, but im not sure, as the equation i used was different. The other equation you found is a paraphrase of the equation listed in the development guide at android.developer.com to describe how the os converts pixels into dip. The reson people tend to quote that is to provide a reference to help others build their own algorithm for scaling appropriate for the jeeds of their app. Hopefully that helps, as its really the best answer i can give at this time. Sorry for any typing errors, im sending this from my phone