当我在x和y的起始位置下面运行代码并且x和y的最终位置渲染时。我希望在tick方法运行时渲染x和y的每个位置,并按速度更改x和y值。基本上我希望能够控制物体移动时的速度。
public void render(Graphics g) {
g.drawImage(JamesTexture.james, x, y, width, height, null);
}
public void tick() {
if (run) {
if (!stop) {
int z = Maze.fx.size() - 1;
int i = 1;// speed
xx = getPathX(z);
yy = getPathY(z);
while (z > 0) {
if (xx > (getPathX(z - 1))) {
xx = xx - i;
x = xx;
if (xx < (getPathX(z - 1))) {
xx = (getPathX(z - 1));
}
} else if (xx < (getPathX(z - 1))) {
xx = xx + i;
x = xx;
if (xx > (getPathX(z - 1))) {
xx = (getPathX(z - 1));
}
} else if (yy > (getPathY(z - 1))) {
yy = yy - i;
y = yy;
if (yy < (getPathY(z - 1))) {
yy = (getPathY(z - 1));
}
} else if (yy < (getPathY(z - 1))) {
yy = yy + i;
y = yy;
if (yy < (getPathY(z - 1))) {
yy = (getPathY(z - 1));
}
} else {
z--;
stop = true; }
}
}
}
}
}
int getPathX(int z) {
List<Integer> fx = Maze.fx;
z = fx.get(z);
return z * 32;
}
int getPathY(int z) {
List<Integer> fy = Maze.fy;
z = fy.get(z);
return z * 32;
}
答案 0 :(得分:0)
只是一个建议,因为我还没有评论,但可能是你的while循环在一次调用中完成了整个迷宫。我认为我们需要更多代码才能确定,但请尝试在while循环中每个 if语句的末尾添加break
语句,如下所示:
if (xx > (getPathX(z - 1))) {
xx = xx - i;
x = xx;
if (xx < (getPathX(z - 1))) {
xx = (getPathX(z - 1));
}
break;
}
检查是否修复了它。它当然取决于调用 tick()函数的速度。
答案 1 :(得分:0)
我知道它可能过度杀死但是Thread类有一个.sleep方法,它以纳秒为参数 线程(以及我认为的程序)将在给定的时间内停止
答案 2 :(得分:0)
没有完美的方法来处理这个问题,因为在实际显示正在渲染的图像之前,您永远无法“预测”花费多少时间。你可以做的是测量前一个标记和当前标记之间经过的时间。
host/sap/bc/srt/wsdl/srvc_00163E5E1FED1EE897C188AB4A5723EF/wsdl11/allinone/ws_policy/document?sap-vhost=host&saml2=disabled
这为您提供了经过的实际增量时间。那么你如何获取滴答时间?我相信Java,Clock,System和Timer类提供各种功能,每个功能都有不同的精度和粒度。通常,这些功能中的一些取决于硬件时钟,一些可能被各种软件和硬件事件中断,一些经验问题当多个硬件核心是上下文切换时,一些可能偶尔甚至倒退..这是一个动物园,你需要阅读文档仔细了解您实际测量的内容。但一般来说,毫秒精度足以满足大多数应用的要求。例如。这样可以在几秒钟内获得时间(作为毫秒范围内具有足够精度的双精度)。
delta time = current tick time - last tick time
速度通常表示为每时间单位的距离,例如
double stime = System.currentTimeMillis();
然后,您可以通过将经过的增量时间乘以速度来计算对象需要移动的距离。
meters per second (m / s)
如果您想减慢对象的移动速度,请降低速度。
如果你有一个非常“稳定”的系统帧率(如果你使用标准的双缓冲这种情况大多是这种情况),你可能会在最后2个滴答之间有一个增量,但当然你可以使用不同的预测方案如果你不定期地进行大量的处理,试着预测减速。获得可预测的帧率是为什么制作好游戏仍然很难做到的。