Slick2D 游戏速度改变
我使用 Swing 创建了一个游戏，它有点不可靠，所以我开始使用 Slick2D 游戏引擎重新制作它，但遇到了问题。
每次调用更新方法时，游戏背景都会以一定的像素在屏幕上滚动。它不断加速和减速，因此背景会移动得非常快，然后又非常慢，并且不断波动。
我已经尝试过* by delta（我认为它监视刷新率！）移动背景的值，但是由于这不会给我一个确切的值，我可以用它来将背景重置到左侧（2个背景移动）从右到左，向右移动 -800 像素）。
造成这种情况的原因是什么以及如何克服它？
谢谢
I created a game using Swing, and it was a bit unreliable, so I started remaking it using Slick2D game engine and I have encountered issues.
The background of the game rolls across the screen at a certain about of pixels each time the update method is called. This keeps speeding up and slowing down, so the background will move very fast, and then very slow, and keeps fluctuating.
I have tried * by delta (which monitors the refresh rate, I think!) on my value which moves the background, but as this wont give me an exact value I can use to reset the background to the left hand side (2 background move from right to left. left hand one goes to the right at -800 pixels).
What is causing this and how do I overcome it?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这里有一些供您阅读的内容（顺便说一句，有一个 特定于游戏开发的 StackExchange 站点）：
这些文章中最重要的一点是，事物随着时间的推移以一定的速率移动，而不是在一定数量的帧上移动。由于帧速率可能会发生不可预测的变化，因此基于时间的运动和基于帧的运动最终并不等同。
这里有一些解释...
因此，您的计算机和操作系统是多线程的，因此您永远无法知道应用程序外部发生了什么，以及计算机上的总体负载是多少。因此，即使您处于全屏模式，您也无法获得对 CPU 的独占访问权。所以，这就是事情加速和减速的因素之一。
Slick2D 中增量的目的是允许您处理这种加速/减速，并允许您的应用动态更改其帧速率，以便屏幕上感知的移动不会因以下原因而改变：您机器上的负载。增量不是显示器的刷新率（它是恒定的）；增量是自上次调用
update以来经过的毫秒数。那么如何正确使用这个增量呢？假设您的背景应该以 100 像素/秒的速度移动。如果增量（在给定的
update调用中）为 33 毫秒，则在此更新中您应移动背景的量为100*(33/1000.0) = 0.033- 因此您可以将背景移动 0.033 像素。这可能看起来很奇怪，您可能想知道移动 <1 像素的意义是什么，但请坚持我的观点。首先，您必须将其除以 1000.0 而不是 1000，是因为您想要 Delta 的移动为您提供一个浮点数。
您会注意到 Slick2D 中的 2D 图形内容使用浮点值来跟踪事物的位置。这是因为，如果增量告诉您将某物移动 0.033 像素，您需要将其移动 0.033：不是 0，也不是 1 像素。子像素移动对于平滑帧速率的增加/减少也至关重要，因为几个子像素移动的累积效应是，当时机成熟时，所有这些小移动加起来就是一个完整的像素，并且它非常平滑，从而产生正确的整体运动速率。
您可能会认为，由于您的屏幕将图像解析为给定像素，而不是子像素元素，因此如果进行子像素移动并不重要，但如果您将所有移动跟踪转换为浮动，您将看到您观察到的效果大部分消失了。
Here's some reading for you (there's a gamedev-specific StackExchange site, BTW):
One of the most important points in these articles is that things move at a certain rate OVER TIME, not over a certain number of frames. Since frame rates can unpredictably change, time-based and frame-based movement don't wind up being equivalent to one another.
And here's some explanation...
So, your computer and OS are multithreaded, and thus, you can never know what's happening outside your app, and what the overall load is on the machine. Because of this, even when you're in full-screen mode you aren't getting exclusive access to the CPU. So, that's one factor to why things speed up and slow down.
The delta's purpose in Slick2D is to allow you to deal with this speed up/slow down, and allow your app to change its frame rate dynamically so that the perceived movement on the screen doesn't change due to the load on your machine. The delta is not the monitor the refresh rate (which is constant); the delta is the number of milliseconds that have passed since the last call to
update.So how do you use this delta properly? Let's say your background is supposed to move at a rate of 100px/sec. If the delta (on a given call to
update) is 33 milliseconds, then the amount you should move your background on this update is100*(33/1000.0) = 0.033- so you would move your background by 0.033 pixels. This might seem weird, and you may wonder what the point is of moving <1 pixel, but stick with me.First, the reason you have to divide it by 1000.0 instead of 1000, is because you want the movement of the delta to give you a floating point number.
You'll notice that the 2D graphics stuff in Slick2D uses float values to track the placement of things. That's because if the delta tells you to move something by 0.033 pixels, you need to move it by 0.033: not 0, and not 1 pixels. Sub-pixel movement is critical to smoothing out the increase/decrease in frame rates as well, because the cumulative effect over several sub-pixel movements is that, when the moment is right, all those little movements add up to a whole pixel, and it's perfectly smooth, resulting in the correct overall movement rate.
You may think that, since your screen resolves images to a given pixel, and not sub-pixel elements, that it doesn't matter if you do sub-pixel movement, but if you convert all your movement tracking to floats, you'll see that the effect you're observing largely goes away.