问题描述
这是一个如何模拟和渲染视频游戏的示例(伪代码).
This is an example (pseudo code) of how you could simulate and render a video game.
//simulate 20ms into the future
const long delta = 20;
long simulationTime = 0;
while(true)
{
while(simulationTime < GetMilliSeconds()) //GetMilliSeconds = Wall Clock Time
{
//the frame we simulated is still in the past
input = GetUserlnput();
UpdateSimulation(delta, input);
//we are trying to catch up and eventually pass the wall clock time
simulationTime += delta;
}
//since my current simulation is in the future and
//my last simulation is in the past
//the current looking of the world has got to be somewhere inbetween
RenderGraphics(InterpolateWorldState(GetMilliSeconds() - simulationTime));
}
这是我的问题:
我有40毫秒的时间通过外部"while true"循环(平均25FPS).RenderGraphics方法需要10毫秒.因此，这意味着我有30毫秒用于内部循环. UpdateSimulation方法需要5毫秒.其他所有值都可以忽略，因为它的值小于0.1ms.
I have 40ms to go through the outer 'while true' loop (means 25FPS). The RenderGraphics method takes 10ms. So that means I have 30ms for the inner loop. The UpdateSimulation method takes 5ms. Everything else can be ignored since it's a value under 0.1ms.
我可以将变量'delta'设置为最大才能保持40ms的时间表(外循环)是多少?为什么呢?
What is the maximum I can set the variable 'delta' to in order to stay in my time schedule of 40ms (outer loop)?And why?
推荐答案
在以下提到的限制条件下，这很大程度上取决于您希望和需要更新仿真状态和用户输入的频率.例如，如果您的游戏包含基于身体行为的内部状态，则需要较小的delta以确保对运动和碰撞(如果有)进行了正确的评估并反映在游戏状态内.此外，如果用户输入需要细粒度的评估和状态更新，则还需要较小的delta值.例如，具有模拟用户输入(例如鼠标，操纵杆)的射击游戏将受益于大于30Hz的更新频率.如果您的游戏不需要如此频繁地评估输入和游戏状态，那么您可以放弃更大的delta值，或者甚至只要检测到玩家的任何输入就可以简单地更新游戏状态.
This largely depends on how often you want and need to update your simulation status and user input, given the constraints mentioned below. For example, if your game contains internal state based on physical behavior, you would need a smaller delta to ensure that movements and collisions, if any, are properly evaluated and reflected within the game state. Also, if your user input requires fine-grained evaluation and state update, you would also need smaller delta values. For example, a shooting game with analogue user input (e.g. mouse, joystick), would benefit from update frequencies larger than 30Hz. If your game does not need such high-frequency evaluation of input and game state, then you could get away with larger delta values, or even by simply updating your game state once any input by the player was being detected.
在特定的伪代码中，仿真将根据长度为delta的固定时间段进行更新，要求您以比要模拟的壁钟时间更短的壁钟时间来处理模拟更新.否则，挂钟时间将进行得比您可以更新的模拟时间快. 这最终会限制您的delta，具体取决于实际可以计算出delta仿真时间的任何仿真更新的速度.这种关系还取决于您的用例，并且可能不是线性的或恒定的.例如，物理引擎通常会将内部给定的delta时间除以它们可以合理处理的更新速率，因为更长的delta时间可能会导致数值不稳定，并且更难解决线性系统，从而非线性地增加了处理量.在其他用例中，仿真更新可能需要线性甚至恒定的时间.即使如此，许多(可能是外部的)事件可能会导致模拟更新的处理速度过慢(如果本质上要求很高的话).例如，在仿真更新期间加载资源，操作系统决定将执行线程搁置一旁，用户运行的另一个进程，防病毒软件启动，内存压力低，CPU速度慢等等.到目前为止，我主要看到两种策略来规避此问题或补救其影响.首先，如果仿真更新工作量较低，并且假设速度下降的原因只是暂时的，则只需忽略它就可以工作.这将导致您的模拟或多或少出现明显的慢动作"行为，在最坏的情况下，这可能会导致模拟时间滞后永远堆积.我经常看到的第二种策略是简单地将要模拟的测量帧时间限制为某个人造值，例如1000ms.一旦减慢的原因消失，这将导致平稳的行为，但具有上限"模拟时间丢失"的缺点，如果不加以处理或考虑不到，这可能会导致动画故障.要选择一种策略，分析您的用例可能包括测量处理delta和x * delta时间的仿真更新所需的挂钟时间，以及更改delta时间和要处理的仿真负载如何实际反映在所需的挂钟时间中进行计算，这将提示您delta的最大值对于您的特定硬件和软件环境.
In your specific pseudo-code, your simulation would update according to a fixed time-slice of length delta, which requires your simulation update to be processed in less wallclock time than the wallclock time to be simulated. Otherwise, wallclock time would proceed faster, than your simulation time can be updated. This ultimately limits your delta depending on how quick any simulation update of delta simulation time can actually be computed. This relationship also depends on your use case and may not be linear or constant. For example, physics engines often would divide your delta time given internally to what update rate they can reasonably process, as longer delta times may cause numerical instabilities and harder to solve linear systems raising processing effort non-linearly. In other use cases, simulation updates may take a linear or even constant time. Even so, many (possibly external) events could cause your simulation update to be processed too slowly, if it is inherently demanding. For example, loading resources during simulation updates, your operating system deciding to lay your execution thread aside, another process run by the user, anti-virus software kicking in, low memory pressure, a slow CPU and so on. Until now, I saw mostly two strategies to evade this problem or remedy its effects. First, simply ignoring it could work if the simulation update effort is low and it is assumed that the cause of the slowdown is temporary only. This would result in more or less noticeable "slow motion" behavior of your simulation, which could - in worst case - lead to simulation time lag piling up forever. The second strategy I often saw was to simply cap the measured frame time to be simulated to some artificial value, say 1000ms. This leads to smooth behavior as soon as the cause of slow down disappears, but has the drawback that the 'capped' simulation time is 'lost', which may lead to animation hiccups if not handled or accounted for. To choose a strategy, analyzing your use case could consist of measuring the wallclock time it takes to process simulation updates of delta and x * delta time and how changing the delta time and simulation load to process actually reflects in wallclock time needed to compute it, which will hint you to what the maximum value of delta is for your specific hardware and software environment.
这篇关于了解简单的模拟和渲染循环的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！