Chipmunk Physics in iTGB

#21 Heh, I have more problems with ObjC than C. I'm still struggling with ObjC syntax, and what to do with square braces! It's baffling!

#22 Keep up the good work Benjamin.

#23 @Benjamin: ObjC is like a vacation in a tropical paradise after struggling with certain C++ projects :)

(Of course, there are shark attacks!)

#24 Ok, made some changes. Someone let me know if this is a "good idea" or "bad idea". I made my physics class a singleton. This way all of the scenegraphs could have access to it when they add objects - but I didn't have to modify a lot of code.

I'm initially adding my physics class to main.cc and keeping a reference there. I'm calling my updateSpace from there. Before I was calling it from the scenegraph, but that was stepping my scene several times (as I'm keeping several scenegraph objects for things like backgrounds).

There are almost no obvious frame rate hiccups (some, but not too bad on a 2G iPhone), but there is some very obvious "stepping" happening that I'm not sure how to smooth out.

#25 I also use many scenegraphs in my games.

Benjamin, I'm getting really excited about this. Do you think you can show us a video of the physics in action?

#26 Bleech.... well, I smoothed out my skipping frames by averaging the pre and post tick distance. But, that is adding some weirdness to my animation. I suppose I can fix this with sprite animation... Looks great on the 3GS, but a 2G still is slow.

@Johnny: Sure. I'll take some videos. It's not building correctly on the simulator some some reason, but I'll sort that out.

#27 Here's a quick video of the physics in-action. This isn't ready for prime-time yet (of course). This is running on a iPhone 2G so It's still a little bit stuttery at times, but you should get the idea of where it's going. I am also writing some tools to clean up the collision boundaries (I was just creating collision lines on every tile spawned... so I was getting some weird bounces).

Anyway, Tilt your head sideways...

www.youtube.com/watch?v=_bJ8W-mnBj0

#28 Yea! Frame rate way up now! Pushed more stuff off to C++. I'm going to try making some more changes and see how solid I can get the framerate on the 2G Phone.

#29 Benjamin, looks excellent. Any idea how that demo would have run with the Torque physics?

#30 Yeah. I tested it with the Torque Physics first. I didn't record anything but it ran at a very similar frame rate, and the physics objects kept getting stuck in each other.

Also, notice how the objects slide easily off of each other. The sphere collisions with Torque acted almost like squares. Spheres would get "caught" on the corners of other spheres.

Now that I have the frame rate up, I'll do another test with a massive amount of objects.

#31 Looks great, but I'm struggling to understand the motivation to implement a different physics engine. I've experienced a lot of weird problems with the iTorque physics engine (things sticking together, is just one example) but I've always found simple workarounds. Is it the overall performance and impact on framerates that you are mostly concerned with? Seems like a lot of work otherwise.

#32 Ok, I didn't see your previous post, it was posted at the same time. If framerates isn't the main issue, I would recommend looking for workarounds. There are loads of simple things you can do to avoid stuff like objects sticking together. Just a thought, but anyway, nice work on the port. If you get it working reliably, I'm sure the effort will be worthwhile :). A lot of people have been complaining about iTorque physics, so if you can find an alternative solution I'm sure you'll make a lot of people happy.

#33 @Mark: A couple of reasons.

I've used box2D before, and the collision callback model of Chipmunk is similar, and something I'm more comfortable with. The difficulty I'm having has more to do with slogging though iTorque's code and figuring out where to hook things up, more than it is actually working with the physics engine.

The game I'm building is very physics based, and I was concerned about accuracy of collisions. After doing some tests with iTorque's built in physics I was unhappy with the results. For a platformer or a puzzle game I would be more than happy.

I didn't want to special case every stuck collision and collision error. I started doing that, and it was looking like more work than to just rip out the physics and replace it. Also, this gives my level designer more freedom to build content without having to debug so much.

As an aside: now that I've made some changes, even with a more complex scene the performance is much better with Chipmunk than it was with iTorque's physics. So, I'm getting better performance with more accurate results. From the sound of it, the new T2D is taking the same approach anyway -- I'll just have it done before them ;).

Yeah - it's a pain in the butt, but I'm getting more intimate with iTGB's guts too.

#34 Benjamin, thanks for you response. Your approach makes sense. In my case I'm only using some very basic physics so it wasn't so hard to find workarounds for certain problems that I encountered along the way. Sounds like you're doing a good job. I guess functionality is your main focus, but if you're getting better performance also then that's an added bonus.

Good luck with the port, and keep us informed.

#35 That the TGB physics is as far from optimally and correctly running as earth is from being a disk (thats where the earth is going to shape wise but we don't know when / if it will ever reach it) is unhappily nothing new. Also already early on (1.0 to 1.1) a user did experimentations with replacing it with Box2D that showed performance differences in a range that GG already back then should have focused and priorized replacing it because the performance was bad and to a large degree is still bad, its just that 3GS+ have cpus fast enough to start compensating for the slugish performance and desinterest to resolve such major issues again. The possibility to disable physics was so far basically the only thing done to resolve the problem but neither VFP nor NEON support nor anything comparable was done (if TGE was developed that badly it would never have gone anywhere but the programmers there did their homework and used MMX, SSE and SSE2)


But from my experience with the pace of this technology I doubt that there was even a single developer fulltime assigned to it which is why we still are plagued by the TGB "physics system" among noobish problems that even let the "new project template generator" for Cocos2D + Box2D shine like pure platinum (not compiling at all, targeting base SDKs that have been declared dead and unsupported before 1.4 even went into QA).
Heck it took till iOS4 until iT2D finally got CADLink rendering, although that is a 3.1 feature and thus around for over 8 months and for games was a must have not a nice to have since 3.1.

Due to the way the whole stuff is working out I personally wouldn't mind if GG would retarget iT2D to become a solid and powerfull editor toolsuite for Cocos2D cause the editor is good and could be great if it got love and Cocos2D does engine wise what iTorque2D will never do anyway because I don't see GG magically change the way they handle technologies nor will their "spread as thin as atomar membran" development scheme change (got only worse since IA took over and the previous leads ran away for better places, not better).
Sometimes its impossible to not think that it is handled as if it was an unloved freeware opensource engine that makes no money and has no obligations to fullfill advertisements.


This is no attack against anyone but an objective statement on how I see the situation due to the time I spent here since day 1 of iT2D, the stuff I've seen advertised, promised and happening and not happening.

#36 @Benjamin - Looks awesome. Sign me up!

#37 Thought I'd drop an update:

I've moved to a variable timestep, because I was getting very different results on the 3GS vs the 3G. The performance difference seems minimally worse, but the gameplay is greatly improved. I'm getting some very minor tunnling, but you really have to work at it to break the collisions. I think in the final product I'm just going to double thickness of walls. If it's too bad after all of the gameplay elements are in place, I'll do a raycast before I launch.

Almost everything (except some simple game logic) has been moved out of script - because I found that just using the script has a huge and noticeable overhead on the iPhone. That's really a little disappointing - I was hoping for better performance with Torquescript, but I'm leaning C++ in a hurry.

@Marc: I may actually use Cocos2D for my next project - iTGB engine modifications are taking the bulk of my time, and that's exactly the opposite of why I decided to use TGB in the first place. My previous experience with TGB has been nothing but positive... but I feel a little taken advantage of with iTGB. I've made so many engine changes at this point (Chipmunk, adding Mod/XM Support, Tweening Menu Support), that I'd be worried about making any engine updates, even to improve performance.

It's going to be difficult to offer a "clean" resource, because I've changed so much at this point. But I'm working on plans for a "clean" implementation after I wrap up my experimentations.

I'll post another video of the changes I've made soon. I'm hoping to have a demo level finished in the next couple days.

#38 This is going to be epic.

#39 Nice work!

One thing that has always confused me is why GG don't encourage more of an Open Source mentality for iTorque. I've seen (and used in my own project) so many good ideas and code workarounds etc from these forums, but I don't think I've ever eperienced GG ever implementing any ideas/bug-fizes that have been donated here. Bugs that were already present six months ago (just a hypothetical example), may be still present in the latest build even if forum regulars already found a good fix and posted it here! Rediculous things like that happen all the time here ....

#40 That's a very good point Mark.