Don’t multiply velocity/position changes with delta time! End of story.
Okay, not quite. There’s a rationale that goes with it. And there are situations where applying delta time is important, if not required - but probably not in the way you’ve been taught by tutorials and fellow developers.
This is important stuff because applying delta time wrongly makes for a bad game experience.
What is this delta time thing anyway?
If you integrate velocity to a node’s position every frame, you have the option to multiply that velocity with the delta time passed in the update: method. Delta time is simply the time difference between the previous and the current frame.
Actually that is not entirely accurate - delta time is the time difference between the last and current execution of the update: method. This usually occurs every frame, but doesn’t have to be. On a scheduled selector that runs every second, the delta time is - tadaa - one second.
Okay, not even that is accurate. On a scheduled selector that runs every second, delta time is at least one second. It could be slightly more. This can depend on the resolution of the timer and how well one second divides with the time allocated to render a frame, or (as you’ll see later) whether time delta was calculated with the same means as the screen refresh rate.
What does multiplying with delta time do?
The effect of (not) multiplying a node’s velocity with delta time is as follows, assuming that 60 fps is the maximum achievable framerate as on iOS:
- Don’t multiply with time delta: the node slows down as the framerate drops below 60 fps.
- Multiply with time delta: the node moves the same distance regardless of the framerate.
Multiplying with delta time is often referred to as “framerate independent” (updates, movement, gameplay, etc). In contrast not multiplying with time delta is often called “framerate dependent” (updates, movement, gameplay, etc).
Unfortunately, framerate independent updates are said to be “important” and often taught by fellow game developers without actually teaching the implications, drawbacks and situations where you don’t want to apply delta time. Here’s one key point to take away early:
Applying delta time only makes a difference when the framerate drops below 60 fps.
If your game always runs at 60 fps there’s absolutely no point to multiply with time delta. If time delta is only used to combat the effect of short-lasting framerate drops, possibly introduced by system events, you’re doing it wrong.
In this case, and most others too, you’re almost always better off not applying delta time on iOS. And if you do, there’s a whole set of things to consider, including the architecture of both the game and the engine.
Continue reading »
I am so very happy to … no, actually I’m relieved Kobold2D is working fine again with the latest Xcode 4.6, including iOS 6 autorotation fixes and the FIX_CATEGORY_BUG issue. Being happy is reserved for whenever I’ve added something nice to KoboldTouch.
Of course I updated cocos2d-iphone to version 2.1-rc0a (on first sight that version looks like being encoded in hexadecimal). Which meant I also had to update cocos2d-iphone-extension to whatever is the current development version - which must be somewhat above 0.21 but that’s hard to tell because there’s no reference of a version number anywhere.
Also updated Chipmunk (6.1.2) and obviously that had to be followed by updating Chimpunk (oh there it is again - my favorite typo today) SpaceManager v0.2.01.
Lastly Admob was playing hard to catch. And it has grown awfully huge, comes with several of Google’s other SDKs as well. Given the dwindling interest in ads by game developers I just pulled the plug and removed AdMob. You can still add it back in to your project according to Google’s instructions though.
That said, here’s the download link for Kobold2D v2.1. Here’s the link to the Release Notes.
I’ll make another update when cocos2d 2.1 is final. The next version is dated for “March” according to the Changelog, but that’s going to be another release candidate. I didn’t want to hold off on updating Kobold2D for the cocos2d 2.1 final version.
PS: There won’t be anymore updates to the Kobold2D v1.x branch.
Since I’ve started to offer KoboldTouch developers have been wondering what will happen to Kobold2D? I’ll answer these questions here.
Kobold2D Updates
When cocos2d 2.1 (stable) is released, I’ll update Kobold2D to include this latest cocos2d version. Same with any other cocos2d version that will be released in 2013. I won’t update to beta versions - sometimes they’re riddled with bugs, other times the next beta comes only a week or two later.
I’ll continue to support and update Kobold2D for as long as there’s interest in it but I’ll definitely focus my efforts on KoboldTouch now.
KoboldTouch “Lite”
Sometime in 2013 (probably not before Q2) I’ll release KoboldTouch “Lite” for free, with limited features and support. This Lite version will then take over as the successor of Kobold2D, while Kobold2D will remain available for some time.
KoboldTouch “Lite” will have the MVC framework but not much else. It will not include any additional features such as OS integration, better tilemap rendering, Box2D Objective-C wrappers and what not.
This ought to help developers get accustomed with the MVC framework.
Relaunch of www.kobold2d.com
Sooner or later I’ll relaunch the www.kobold2d.com website as www.koboldtouch.com. I’ll go for a simple look & feel (KISS), it will include the Kobold2D articles and I’m going to write all KoboldTouch documentation publicly.
For one this will make it easier for me to write and publish documentation. It should also help KoboldTouch’s popularity to reveal its documentation to both developers and search engines.
KoboldTouch compatibility with Kobold2D
KoboldTouch is not 100% compatible with Kobold2D, since I’ve already trimmed the less popular libraries from KoboldTouch: Chipmunk, Chipmunk Spacemanager, Cocos3D, ObjectAL, SneakyInput, iSimulate, AdMob. The remaining libraries are: cocos2d-iphone, cocos2d-iphone-extensions, CocosDenshion, Kobold2D, Box2, Lua and a few smaller additions (BitArray, LOG_EXPR, etc).
You should be able to port code that does not use one of these libraries with ease. Though without adapting to the MVC framework you lose a lot of the benefits of using KoboldTouch.
Custom Folders and Source Control
Issues regarding custom folders and source control usage come up frequently. I will alleviate those with KoboldTouch.
The project starter tool will be improved to support creating new projects in a custom folder, with or without copying the offline documentation to the new folder. The project upgrader tool will also work with custom folder locations.
The documentation accounts for most of the disk space usage of a Kobold2D/KoboldTouch project and should therefore not be included when you intend to manage this project with source control. Specifically if it’s an online repository with limited disk space. With the additional libraries stripped and documentation not included, a new KoboldTouch project weighs in at around 15 MB of disk space.
What will remain is that the installer will install to a fixed folder, since you will then be able to create new projects in any custom folder so there’s no real need for a custom folder location during installation.
There are plenty of issues with PackageMaker to overcome to support custom folder locations and I’d rather spend that time on other things. As was always the case, you can of course move the Kobold2D folder anywhere else after the installation completed - it’s just one click & drag operation in Finder.
Your question not answered here?
Let me know by writing a comment.
Kobold2D v2.0.4 is now available for download, as is v1.0.3.
Both versions contain compatibility fixes for iOS 6, Xcode 4.5, Mountain Lion and a few extra features like (finally) Kobold2D Class Templates for Xcode.
The Most Important Changes & Additions
- fixed: iOS 6 initial rotation issue
- iPhone 5 widescreen enabled in all template projects
- Existing projects must add a [email protected] image with size of 640×1136 pixels to their project to enable iPhone 5 widescreen support.
- Mountain Lion: no need to lower security level to run Installer. Package is now signed by “identified developer”.
- NEW: Kobold2D Class Templates available in Xcode.
- Use as basis for new CCNode class files. Includes stubs of frequently used methods: init, onEnter, cleanup, dealloc, update.
Continue reading »
- Use as basis for new CCNode class files. Includes stubs of frequently used methods: init, onEnter, cleanup, dealloc, update.
I just released a compatibility update for Kobold2D since there were numerous compiler warnings and errors introduced in Xcode 4.4.
Almost all of the issues were simply the compiler being more adamant about using the correct type specifiers in format strings. For example using %i for an unsigned integer or %u for an unsigned long type would bring up warnings. The solution is to use either the correct format specifier or casting the value. The latter is preferable if the underlying type changes depending on the platform. For example NSUInteger is unsigned int for iOS but on Mac 64-Bit it’s actually unsigned long.
You can get the updated Kobold2D v1.1.2 and v2.0.3 versions from the Kobold2D Downloads page. Continue reading »
Get the latest versions of Kobold2D from the download page and more details in the Release Notes.
Kobold2D v1.1.1 has been updated to include the latest version of cocos2d-iphone v1.1 (beta2b) from May 3rd this year. This version supports the -ipad and -ipadhd suffixes.
Both Kobold2D v1.1.1 and v2.0.1 have been updated to include the latest Chipmunk v6.1.1 and Chipmunk SpaceManager v0.1.3. Although unfortunately SpaceManager still isn’t fully compatible with cocos2d-iphone 2.0 because it still won’t rotate the sprites.
Again both versions include an important fix for KKInput: I’ve received several reports where users complained that KKInput is missing some events. Specifically the “ThisFrame” variants were prone to never fire. This is now fixed.
Line-Drawing Game Starterkit: ARC + cocos2d v1.1 & v2.0
While I’ve been meddling with Kobold2D updates I found this to be the perfect opportunity to update the Line-Drawing Game Starterkit as well. You now get four versions of the project, two are using cocos2d-iphone v1.1 and the other two have been updated to work with cocos2d-iphone v2.0.
And each of the two cocos2d-iphone version projects allows you to choose between the ARC enabled project or the classic manual reference counting project. The included readme document explains this in greater detail. Suffice it to say you can simply choose with which to start: cocos2d v1.1 or v2.0 and either with ARC enabled or manual reference counting.
Of course I strongly recommend the cocos2d-iphone v2.0 version with ARC enabled, seeing how the old devices have an ever diminishing, probably below 15% market share.
And do use ARC, it’s really a no-brainer not to bother with reference counting anymore.
If you’re an existing customer, you should have received an update email with your download link.
In this episode you can see the Cocos2D Webcam Viewer in action. I also show you how to update a sprite’s texture while your app is running just by saving an updated version of the image, and how cool that actually is!
The second half of the video is devoted to explaining my work schedule. I’d like to believe that I have a unique and interesting solution to planning but I’m sure in some way or another it’s already been implemented.
I’m certainly influenced by Agile Development as much as I am by books like Getting Things Done and The 4-Hour Workweek. My revelation was simply this: stop wasting time planning tasks! Instead, plan your time and how you spend it.
Episode #4 - I see Road Nuts
• iDevBlogADay: Cocos2D Webcam Viewer
o Mac OS X Webserver File Download
• Kobold2D v1.0.2 released
• Poll: Which scripting language for Cocos2D?
• My work schedule explained
