NSTimer vs CACurrentMediaTime() [英] NSTimer vs CACurrentMediaTime()

查看:97
本文介绍了NSTimer vs CACurrentMediaTime()的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我正处于我的第一个iOS游戏中,并且正在努力寻找如何整合对象移动的最佳方法。



游戏在很大程度上依赖于快速移动的物体和持续快速的用户输入变化。因此,我试图让对象集成和约束求解器尽可能快速准确地运行(以最小化连续游戏循环调用之间的用户输入变化)。



更具体地说,我不确定NSTimer类和CACurrentMediaTime()函数的功能。很难根据经验进行测试,因为我不确定哪个有更大的错误。例如,使用重复间隔为0.008(~2updates /屏幕刷新)的NSTimer并在连续调用时调用CACurrentMediaTime(),我发现调用之间的时间间隔在0.0075 - 0.009之间变化。很难说哪个是(小)不一致的原因。因此,我应该确定时间步长:


  1. 假设NSTimer足够精确,可以将NSTimer时间间隔用作游戏循环时间步


  2. 使用CACurrentMediaTime()来确定连续游戏循环调用之间的时间间隔。


学生和所有这些的新手 - 请保持友好:)非常感谢任何建议。谢谢你的时间。

解决方案

NSTimer 不是实时的计时器。它甚至不是很接近,也不是故意的。如果您正在查看任何超过半秒的时间, NSTimer 是错误的工具。我甚至不推荐它用于不到一秒钟的事情。对于多秒钟的事情,特别是多分钟的事情,如果你真的不关心什么时候开火,那就太棒了。我一直都在使用它。



CACurrentMediaTime()不是计时器。它是系统中最准确的时间函数的包装器: mach_absolute_time()。因此,如果您真正关心它现在的时间,并且您希望以人类可理解的数字, CACurrentMediaTime()是您的功能。 mach_absolute_time()会给你一个非常准确的数字,但它是基于每个绝对时间单位,它实际上并没有映射到人类认为的任何麻烦(并且每个CPU都有不同的比例)。这就是为什么我们有 CACurrentMediaTime()来让我们的生活更轻松。



好的,所以 NSTimer 不是实时的, CACurrentMediaTime()不是计时器。什么是游戏程序员?



Grand Central Dispatch 包括我们拥有的最好的使这次运行系统中的一些。这是一个调度源。我说关于这个时间,因为GCD仍然不像RTOS家伙那样真正实时。但对于游戏开发者来说,这是实时的。在并发编程指南。另外看一下 dispatch_after(),这对于一次性延迟运行很有帮助。



<请记住,在主线程(UI线程,完成所有绘图)上运行的任何内容都将与该线程上的其他内容共享时间。因此,当您在主线程上处理绘图和用户交互时,通常需要在后台线程上进行计算。这是GCD dispatch_queues旨在帮助您的那种东西。另一方面,请记住许多iOS设备都是单核的。所以背景线程有点用词不当。在CPU上一次只能运行一件事。这就是为什么将内容移动到GPU是如此重要(见下文)。



你可能也想认真看待像 cocos2d ,这是一个非常好的游戏引擎。它会为你处理很多这样的细节,让你专注于游戏部分。



留在Apple框架中,你还应该看看Core动画。如果你用计时器在屏幕上移动东西,你不应该这样做。核心动画是你在屏幕上移动东西的方式。它可以为您提供更多细节,更快,使用的电量比您自己的电池少得多,并且它将大量工作转移到GPU上(如上所述)。它设计的UI元素比游戏更多,但它绝对可以用来构建简单的游戏。



当然还有GLKit,但这是完全不同的事情。 ......


So I'm amidst my first iOS game and am struggling with how to go about the best way to integrate object movement.

The game relies heavily on fast moving objects and constant, fast user input changes. As such, I'm trying to have object integration and the constraint solver run as quickly and accurately as possible (to minimize user input change in between successive game loop calls).

More specifically, I'm unsure of the capabilities of the NSTimer class and CACurrentMediaTime() function. It's hard to test empirically because I'm not sure which have the larger error. For example, using an NSTimer with a repeating interval of 0.008 (~2updates/screen refresh) and calling CACurrentMediaTime() on successive calls, I find the time interval between calls varies from 0.0075 - 0.009. Hard to say which is responsible for the (small) inconsistency. So for determining the time step should I be:

  1. Assume NSTimer is accurate enough to use the NSTimer time interval as the game loop time step

  2. Use CACurrentMediaTime() to determine the time interval between successive game loop calls.

Student and new to all of this - please be nice :) Any advice is greatly appreciated. Thanks for your time.

解决方案

NSTimer is not a real-time timer. It's not even close, nor does it mean to be. If you're looking at anything faster than about half a second, NSTimer is the wrong tool. I wouldn't even recommend it for things under a second. For multi-second things, and particularly multi-minute things, when you don't really care exactly when it fires, it's great. I use it all the time.

CACurrentMediaTime() is not a timer. It's a wrapper around the most accurate time function in the system: mach_absolute_time(). So if you really care what time it is right now, and you'd like that in a human-understandable number, CACurrentMediaTime() is your function. mach_absolute_time() will give you a really accurate number, but it's based on the Mach absolute time unit which doesn't actually map to anything pesky humans think in (and every CPU has a different scale). That's why we have CACurrentMediaTime() to make our lives easier.

OK, so NSTimer isn't for real-time, and CACurrentMediaTime() isn't a timer. What's a game programmer to do?

Grand Central Dispatch includes some one of the best "make this run at about this time" systems we have. It's a Dispatch Source. I say "about this time" because GCD still isn't really "real time" in the way that RTOS guys mean it. But it's realtime enough for game developers. Look for Creating a Timer in the Concurrency Programming Guide. Also take a look at dispatch_after(), which is good for one-shot "run this after a delay."

Remember, anything that runs on your main thread (the UI thread, where all the drawing is done), is going to share time with everything else on that thread. So often you're going to need to do calculations on a background thread while you handle drawing and user interaction on the main thread. This is the kind of thing that GCD dispatch_queues are designed to help you with. On the other hand, remember that many iOS devices are single-core. So "background thread" is a bit of a misnomer. Only one thing can really run at a time on the CPU. That's why moving things to the GPU is so important (see below).

You may also want to seriously look at systems like cocos2d, which is a very good game engine. It takes care of a lot of these kinds of details for you and lets you focus on the game part.

Staying in Apple frameworks, you should also take a look at Core Animation. If you're moving things around on the screen with timers, you shouldn't be doing that. Core Animation is how you move things around on the screen. It takes care of a lot of details for you, faster and using much less battery than you'd do on your own, and it moves a lot of the work to the GPU (as I mentioned above). It's a bit more designed for UI elements than games, but it can definitely be used to build simple games.

And of course there's GLKit, but that's a whole different thing....

这篇关于NSTimer vs CACurrentMediaTime()的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆