Chipmunk Physics in iTGB
by Benjamin Cole · in iTorque 2D · 09/07/2010 (2:33 pm) · 87 replies
Hi There,
I am working on replacing iTGB's physics with something lighter and friendlier and running into some difficulties. I am just learning how XCode structures projects, so it's been like pulling teeth so far.
I'm not delving into the actual T2D source, and I'm a little puzzled as to what actually needs to be stripped and replaced. Ideally, I'd like to keep the tourqueScript callbacks, and have chipmunk or Box2D silently replace the physics, even if I lose some of the additional functionality that these platforms offer (really, I'm only doing circle on circle and circle on tilemap collisions anyway).
I'm trying to figure out where the physics scene in TGB is setup, where objects are added, and where the physics steps are actually called. I'm assuming each object is created as a t2dSceneObject, and the physics setup and step should be in the t2dSceneGraph... but I'm having trouble finding out where this actually occurs. I'm not a C++ expert, but I know my way around OOP and the source is pretty readable.
Can anyone who has done this point me in the right direction?
I am working on replacing iTGB's physics with something lighter and friendlier and running into some difficulties. I am just learning how XCode structures projects, so it's been like pulling teeth so far.
I'm not delving into the actual T2D source, and I'm a little puzzled as to what actually needs to be stripped and replaced. Ideally, I'd like to keep the tourqueScript callbacks, and have chipmunk or Box2D silently replace the physics, even if I lose some of the additional functionality that these platforms offer (really, I'm only doing circle on circle and circle on tilemap collisions anyway).
I'm trying to figure out where the physics scene in TGB is setup, where objects are added, and where the physics steps are actually called. I'm assuming each object is created as a t2dSceneObject, and the physics setup and step should be in the t2dSceneGraph... but I'm having trouble finding out where this actually occurs. I'm not a C++ expert, but I know my way around OOP and the source is pretty readable.
Can anyone who has done this point me in the right direction?
#42
Don't get me wrong, iTGB is super powerful. I've been working with Corona SDK and torque for 2d game is better, but loses alot of points for no real physics engine. Alot of great developers here can work around 1.4, but for many of us fixing bugs can take days or weeks... not funny.
@Benjamin - I'm willing to follow your resource - even if its difficult - to get chipmunk support in iTGB!
10/03/2010 (6:03 pm)
I agree with you guys, 1.4 added some features but broke many many more... why? To me it seems like Torque is logging a bug a week. When they plan to fix it... who knows. We all paid 750 for the product, and all I am asking is that the features that are advertised work without any problems. Don't get me wrong, iTGB is super powerful. I've been working with Corona SDK and torque for 2d game is better, but loses alot of points for no real physics engine. Alot of great developers here can work around 1.4, but for many of us fixing bugs can take days or weeks... not funny.
@Benjamin - I'm willing to follow your resource - even if its difficult - to get chipmunk support in iTGB!
#43
I think I'd be much happier with just an input system, a sprite rendering engine, and the UI tools. Otherwise, in my opinion it's just REALLY bulky. There is a lot of things I don't understand about the engine, so it's hard to figure out what's essential and what isn't. It seems like it's supposed to be an easy TGB to iTGB tool, but obviously this isn't the case. It may be better to... you know... be upfront with that.
10/04/2010 (1:29 am)
@Mark - I don't think iTGB in general can really go open source. In fact, I'm not sure how it would - especially if they are still trying to sell TGB too.I think I'd be much happier with just an input system, a sprite rendering engine, and the UI tools. Otherwise, in my opinion it's just REALLY bulky. There is a lot of things I don't understand about the engine, so it's hard to figure out what's essential and what isn't. It seems like it's supposed to be an easy TGB to iTGB tool, but obviously this isn't the case. It may be better to... you know... be upfront with that.
#44
One thing you could look at, if you're a masochist, crazy and have too much spare time, is the string lookup thing. Several of us suspect it's a ticking time bomb of memory leaks ;)
10/04/2010 (3:01 am)
There's RedBook audio code in there! Dead, unused code. Doesn't help size if it's still referenced (but not used) from some other part of the code. There is probably more of that sort tucked away in the code.One thing you could look at, if you're a masochist, crazy and have too much spare time, is the string lookup thing. Several of us suspect it's a ticking time bomb of memory leaks ;)
#45
There always were problems in TGB but on the desktop they were hidden often by the computer. One thing though was already known over there and thats that rather simple games easily need several hundred MB of RAM to even run or that the "physics" system is horrible at best, the only thing it did right at any time is the swept polygon collision basically. Also beyond the point where Melv left, TGB went down "the toilet" quality and performance wise and iTGB unpleasantly built upon 1.7.x instead of building upon 1.1.3 or 1.1.3 + fixes from later versions, as it was worlds more solid (yes behaviors are nice but no behaviors are not a smart idea at all on the idevices if you know how the script core works, due to their continous nature of calling instead of the discrete way of callings on datablock classes. components didn't solve that as they still have relationships to scripts) and not rarely even more performant, not talking about the lower amount of RAM that it burnt (1.1.3 was much closer to the top class optimizations TGE had which is in the torque engines likely still the only one that really unleashed the hw power at its time ... all others relied on the systems being fast enough to compesate for shortcuts)
10/04/2010 (3:22 am)
I unpleasantly (in this case) have too much knowledge of how the inner stuff works due to working a long time with TGE and TGEA (especially the last milestones and the horrible 1.0.x versions) as well as TGB Pro since 0.7There always were problems in TGB but on the desktop they were hidden often by the computer. One thing though was already known over there and thats that rather simple games easily need several hundred MB of RAM to even run or that the "physics" system is horrible at best, the only thing it did right at any time is the swept polygon collision basically. Also beyond the point where Melv left, TGB went down "the toilet" quality and performance wise and iTGB unpleasantly built upon 1.7.x instead of building upon 1.1.3 or 1.1.3 + fixes from later versions, as it was worlds more solid (yes behaviors are nice but no behaviors are not a smart idea at all on the idevices if you know how the script core works, due to their continous nature of calling instead of the discrete way of callings on datablock classes. components didn't solve that as they still have relationships to scripts) and not rarely even more performant, not talking about the lower amount of RAM that it burnt (1.1.3 was much closer to the top class optimizations TGE had which is in the torque engines likely still the only one that really unleashed the hw power at its time ... all others relied on the systems being fast enough to compesate for shortcuts)
#46
I don't have too much spare time right now (although I do seem to be somewhat of a masochist -- and crazy)... I'd really like to get this game out. If everyone buys it, and convinces about a dozen friends to buy it, I could find the time to try and fix it in an update ;).
Seriously though, have you seen serious memory leaks? Really though, any memory leaks on the iPhone is kind of serious. I haven't done any profiling looking for leaks yet.
10/04/2010 (3:26 am)
@Ronny - I've commented out almost all of T2DAnimatedSprite and T2DSceneGraph... I'm looking at vast blankets of unused code now.I don't have too much spare time right now (although I do seem to be somewhat of a masochist -- and crazy)... I'd really like to get this game out. If everyone buys it, and convinces about a dozen friends to buy it, I could find the time to try and fix it in an update ;).
Seriously though, have you seen serious memory leaks? Really though, any memory leaks on the iPhone is kind of serious. I haven't done any profiling looking for leaks yet.
#47
10/04/2010 (3:26 am)
Benjamin, I wasn't meaning they should go full blown open source. I was thinking more in terms of some mechanism that would allow and even promote community code making it into the actual product. I'm sure the legal issues could be sorted out, and there must be so much useful stuff on here that's accumulated over the years.
#48
10/04/2010 (1:55 pm)
@Benjamin: The code is a house of cards. It's improved greatly over the past few releases, so it might not be so leaky anymore. But a few kilobytes here and there seem to disappear (which is acceptable, really).
#49
@Ronny - I suspect I have some issues in my code causing leaks. I would really like to blame the engine though, so let's just blame it on that for now ;).
Also, as an aside. I was looking over the Unity forums, and it sounds like people there are having similar performance issues on the older phones as well. It's likely the same using any middleware. It sure makes your life easier though.
10/05/2010 (10:24 am)
@Mark - Is there a reason that the community couldn't maintain their own SVN? Or GG open up access to a "community" build that registered users could maintain. I know piracy is always an issue - but really, I don't think their current solution is doing much to curtail casual piracy anyway.@Ronny - I suspect I have some issues in my code causing leaks. I would really like to blame the engine though, so let's just blame it on that for now ;).
Also, as an aside. I was looking over the Unity forums, and it sounds like people there are having similar performance issues on the older phones as well. It's likely the same using any middleware. It sure makes your life easier though.
#50
Moved my physics step OUT of main.cc and extended t2dSceneWindow into a t2dPhysicsScene class. Added my physics step to onRender instead, and saw another pretty decent speed increase. I'm not exactly sure why though - anyone know why this may be the case?
10/05/2010 (9:15 pm)
Quick update on progress:Moved my physics step OUT of main.cc and extended t2dSceneWindow into a t2dPhysicsScene class. Added my physics step to onRender instead, and saw another pretty decent speed increase. I'm not exactly sure why though - anyone know why this may be the case?
#51
The game runs at a 25-30 FPS no problem when I "Build and Run" though Xcode, but grinds to a halt when I launch the game though springboard. Does anyone have ANY ideas what would be causing this? It's a little frustrating, because I can't use the profiler...
Anyone?
10/06/2010 (9:14 pm)
I've got a new problem:The game runs at a 25-30 FPS no problem when I "Build and Run" though Xcode, but grinds to a halt when I launch the game though springboard. Does anyone have ANY ideas what would be causing this? It's a little frustrating, because I can't use the profiler...
Anyone?
#52
10/06/2010 (9:25 pm)
Have you tried a reboot of the device?
#53
10/06/2010 (9:27 pm)
Yeah. I've tried rebooting. I can't see a noticeable difference. I've also given a build to my partner and he's seeing the same thing.
#54
10/06/2010 (9:30 pm)
Has it always been like this or is it a recent change you've made? Is this a shipping build?
#55
10/06/2010 (9:38 pm)
I'll start by asking the almost insultingly obvious: are you absolutely sure you're running the same app when you launch from Springboard? Like, absolutely ? :)
#56
I partially solved the problem by changing my build to "shipping". But now "build and go" is giving me around 40FPS, and springboard is giving me 25-30FPS.
Playable for sure, but the discrepancy is driving me nuts!
10/06/2010 (10:06 pm)
Haha! Yeah, I added a build number to the display just to be sure.I partially solved the problem by changing my build to "shipping". But now "build and go" is giving me around 40FPS, and springboard is giving me 25-30FPS.
Playable for sure, but the discrepancy is driving me nuts!
#57
... my code on the other hand is leaking all over the place because I malloc'd a string to send a collision response back to script - but that's totally my fault and an extremely easy fix. I just forgot about it.
Also, that's not slowing down anything. If I'm reading this correctly, I only have allocated 10.65MB for everything (including leaks). I'd say that's pretty reasonable.
10/06/2010 (11:26 pm)
As an aside. I just ran leaks on my game, and it seems Torque leaked exactly 16 bytes in something called PurplePushEvent (I have NO idea what this may be).... my code on the other hand is leaking all over the place because I malloc'd a string to send a collision response back to script - but that's totally my fault and an extremely easy fix. I just forgot about it.
Also, that's not slowing down anything. If I'm reading this correctly, I only have allocated 10.65MB for everything (including leaks). I'd say that's pretty reasonable.
#58
10/07/2010 (1:40 am)
depends on what "all" means ... on a pre 3GS device thats something between 30% and 60% of the available ram
#59
I know the system takes up a fair amount of resources, but how much am I actually working with? Is there anything I can use to check free ram on the iPhone?
10/07/2010 (1:46 am)
"All" meaning all loaded code and assets. I have my memory footprint pretty solidified for the main game. I'm loading dummy objects at full resolution for just about everything and have my sound system playing kind of a worst case scenario.I know the system takes up a fair amount of resources, but how much am I actually working with? Is there anything I can use to check free ram on the iPhone?
#60
if you use too much you will throw get the application memory warning thrown at you which indicates that you either clear unused assets or you will get another chance to do so (warning level 2).
there won't be a level 3 warning, level 3 will result in a direct kill signal from the OS
thats what you are meant to work with.
but 10mb for all sounds rather solid indeed :)
10/07/2010 (2:19 am)
no, there is no official function for checking free ram.if you use too much you will throw get the application memory warning thrown at you which indicates that you either clear unused assets or you will get another chance to do so (warning level 2).
there won't be a level 3 warning, level 3 will result in a direct kill signal from the OS
thats what you are meant to work with.
but 10mb for all sounds rather solid indeed :)
Torque 3D Owner Marc Dreamora Schaerer
Gayasoft
And I agree on Cocos2D. Also with officially support for TilED Cocos has solved on of its primary problems as well.
That Cocos has about 200 to 500 times the amount of games on the appstore as iTGB is a good indicator on quality and performance unhappily, cause independent of how nice TGB is or was on the computer (where the hardware solved some of its major problems by just being overpowered normally), on the iPhone it requires significant work and just doesn't get it.
Its a shame and rather annoying at the prime price it costs, would due to my experience since its release by now actually rather donate that to the cocos devs as I know at least that there is someone working on it, which I am unsure for iTGB. 1.4.1 should have happened long ago as it is a bugfix release, no new major thing, which should have solved bugs that never must have passed the QA at all and I'm getting less and less patient on the matter.
I'm sorry Michael but could we finally get some binding informations on the matter of iTGB and GGs plans to solve issues that were meant to be solved months ago or shouldn't even have been present at all since day 1?
I'm sick of the hide and seek games played with paying customers here. Its over 1.5 years since release if not longer, yet the technology still isn't there, versions that don't even compile pass through your so called fictive QA department and things like that and its time that you either declare iTGB as dead, make it opensource so people can fix it up for you so it gets really used (will not happen at the time as people will rather switch technology than showing your logo if it was their hard work on the engine side fixing it making the game happen at all!) or that you get it to the real version 1.0, ie its first solid and just WORKING release!