![]() |
1
22
不要把游戏的逻辑(物体移动等)更新速度建立在帧速率上。换句话说,将图形和逻辑更新代码放在两个单独的组件/线程中。这样你的游戏逻辑就完全独立于你的帧率。
逻辑更新应该基于自上次更新以来经过的时间(我们称之为
这是计算逻辑更新对象(在某个线程循环中运行)中的增量的一种方法:
示例代码:
这个活动课不太重要。您可以忽略其中的大部分代码。
|
![]() |
2
3
我在想,上面的一些代码可能不是真的有问题,而是效率低下。我说的是这个密码。。。
具体来说,我在想以下几句话。。。
在我看来,让线程挂起什么都不做是在浪费宝贵的处理时间,而实际上你要做的是执行更新,那么,如果更新所用的时间少于25毫秒,然后让线程休眠,看看更新过程中使用了什么和25毫秒(或者你选择的帧速率是多少)。这样,更新将在渲染当前帧时发生,并将完成,以便下一帧更新使用更新的值。 这里我能想到的唯一问题是,需要进行某种同步,以便当前帧渲染不使用部分更新的值。可能会更新到值集的新实例中,然后在渲染之前将新实例设为当前实例。 我记得我在一本图形学书中读到过这样一段话:目标是尽可能多地执行更新,同时保持在所需的帧速率范围内,然后,并且只有他们才执行屏幕更新。
所以,在代码中,它更像是。。。
巴巴蒂 |
![]() |
3
0
|
![]() |
4
0
如果你的游戏是动作密集型的,我会使用SurfaceView而不是View。如果不需要快速更新GUI,那么View就可以了,但是对于2D游戏来说,最好使用SurfaceView。 |
![]() |
5
0
郁闷-你说一个SurfaceView是beter,但是,这不是真的在android3.0之后,因为视图是HW加速的,但是canvas返回的.lockCanvas不是。 史蒂文-是的,这很可能会引起问题,但很容易发现。 /雅各布 |
![]() |
Murilo · Jetpack编写导航栏项目图标 6 月前 |
![]() |
KolaYAndr · 活动RESULT_OK似乎从未发生过 6 月前 |
![]() |
psycho_pat · Android应用程序中的权限 7 月前 |
|
FarazFiroz · 如何将argb转换为描述性文本颜色 7 月前 |
![]() |
Daniel · Unity Android游戏支持的设备数量太少 7 月前 |