Recursion for iPhone
by Joe Virgin · in iTorque 2D · 10/21/2009 (6:44 pm) · 4 replies
I've noticed that how you handle recursive functions (i.e. functions that repeat themselves) makes a huge difference in the frame rates of the game. While I've seen threads on how one type of recursion beats another, I'd like to know what is the most efficient way to create recursion (e.g. scheduling, onTimer, onUpdate) for the iPhone?
About the author
Joe Virgin is a programmer for Plainvue Software, Inc., a company producing iPhone games that teach math skills to the youth. Check out Fraction's Kitchen Lite, Fortune's Prime, and Chainshooter powered by iTGB and now available on the App Store.
#2
Failing that, avoid it. Even if it breaks a mathematician's heart ;)
10/21/2009 (8:11 pm)
Best recursion = in C :)Failing that, avoid it. Even if it breaks a mathematician's heart ;)
#3
10/21/2009 (9:45 pm)
Out of those three alternatives, I use onTimer. You can throttle your performance a little but by adjusting how often the function is called. onUpdate is fairly intensive by comparison. Schedule calls are really best for single events. It takes more code to implement the same functionality as onTimer when you use them, and I personally prefer to keep code short / simple.
#4
I personally would hate to do all the recursion in C, but can definitely see how it would be efficient for the processor. Furthermore, I agree with the onUpdate recursion being very costly. I'm still in the air between recursive scheduling and onTimer though.
Schedules have the nice feature of associating themselves with objects so that if the object gets deleted, the schedule gets canceled. Plus, schedules have event IDs and functions that can work upon the event IDs for scheduling management.
onTimer lacks this management, which is unfortunate, but may in the end be more efficient for the processor.
10/22/2009 (3:55 pm)
Thanks for the responses. Please don't feel restricted to the three I mentioned, I was just using them as examples.I personally would hate to do all the recursion in C, but can definitely see how it would be efficient for the processor. Furthermore, I agree with the onUpdate recursion being very costly. I'm still in the air between recursive scheduling and onTimer though.
Schedules have the nice feature of associating themselves with objects so that if the object gets deleted, the schedule gets canceled. Plus, schedules have event IDs and functions that can work upon the event IDs for scheduling management.
onTimer lacks this management, which is unfortunate, but may in the end be more efficient for the processor.
Torque Owner Eyal Erez
As far as onTimer vs scheduling it would be great to know the answer.