Worries with ITGB - Dust Bunnies Quotes
by Jason Darby · in Torque 2D for the iPhone · 07/29/2009 (4:16 am) · 19 replies
Moderator Note: Stickying this thread for a bit so other users can read the tips posted by developers who have shipped iPhone games using the engine
There is an interview with Blue Omega about a game they made using Torque... here are some direct quotes from them that really get me concerned about making a game with iTGB... considering as far as i can tell it doesnt mention these issues anywhere on the product purchase pages. Seriously worrying that you buy a product and it uses script and you have to by the sounds of things throw it away and write/convert in C++....
So I am not sure what Garagegames are actually trying to sell me here, a product that you generally use scripting (TGB) in and by the sounds of things is made totally redundant when you need it for the iPhone. So anyone with iTGB can shed any light on the development from TGB... as $650 is alot of money for something that may not give me what i need/
There is an interview with Blue Omega about a game they made using Torque... here are some direct quotes from them that really get me concerned about making a game with iTGB... considering as far as i can tell it doesnt mention these issues anywhere on the product purchase pages. Seriously worrying that you buy a product and it uses script and you have to by the sounds of things throw it away and write/convert in C++....
Quote:
After just over a month of development time, it became apparent that we could not use TorqueScript for the majority of our game. The very first time we ran Attack of the Dust Bunnies on the iPhone, it was running around 2 FPS - this was when the game was mostly written in TorqueScript
Quote:
There are not many changes we would make to the game. The biggest difference would be trying to develop the game using mainly C++ rather than developing it in TorqueScript first and then converting it to C++.
So I am not sure what Garagegames are actually trying to sell me here, a product that you generally use scripting (TGB) in and by the sounds of things is made totally redundant when you need it for the iPhone. So anyone with iTGB can shed any light on the development from TGB... as $650 is alot of money for something that may not give me what i need/
About the author
Computer games book author, have written 6 game creation books, published by Cengage Course Technology. Owner of Arcade website www.madword.com and Castle software.
#2
iTGB gives you a pretty powerfull TGB based technology to use it on the iPhone.
But due to the nature of the iPhone, its constraints can be very impacting.
You can use scripting up to a given point, but anything thats calculation heavy or object heavy basically requires the usage of C++ for parts of it at very least (could be done through components, the C++ counter end to behaviors), there is just no way around that, because although iTGB got an optimized script core, its still scripted code thats beeing interpreted on the iPhone which is a pretty slow operation on the type of CPU it has.
The required knowledge in C++ for this task does not go much further than what you know from TorqueScript already, so its not like you must become a C++ master. The behavior shooter is actually offered in two different versions with iTGB, the regular one and one that uses Components, so you can learn from this for example.
The requirement naturally is that you are willing to learn new things to the point required.
As the time goes on, you will learn more about C++, about the TGB sources and will become capable to alter the behavior in a much more impacting way to create things you wouldn't be able to do with scripts at all (on the iPhone and the desktop)
07/29/2009 (4:36 am)
Its actually $750 unless you already own the normal nonsource TGB.iTGB gives you a pretty powerfull TGB based technology to use it on the iPhone.
But due to the nature of the iPhone, its constraints can be very impacting.
You can use scripting up to a given point, but anything thats calculation heavy or object heavy basically requires the usage of C++ for parts of it at very least (could be done through components, the C++ counter end to behaviors), there is just no way around that, because although iTGB got an optimized script core, its still scripted code thats beeing interpreted on the iPhone which is a pretty slow operation on the type of CPU it has.
The required knowledge in C++ for this task does not go much further than what you know from TorqueScript already, so its not like you must become a C++ master. The behavior shooter is actually offered in two different versions with iTGB, the regular one and one that uses Components, so you can learn from this for example.
The requirement naturally is that you are willing to learn new things to the point required.
As the time goes on, you will learn more about C++, about the TGB sources and will become capable to alter the behavior in a much more impacting way to create things you wouldn't be able to do with scripts at all (on the iPhone and the desktop)
#3
07/29/2009 (4:39 am)
Thanks for the more in-depth explanation Marc! 
#4
07/29/2009 (4:54 am)
yeah, keep in mind this totally depends on the type of game you are making. We made a game that was not event driven and was driven by a game loop. This is generally frowned upon when working with iTGB. However, thanks to the flexibility of the engine (and having access to the source code) we were able to get great performance out of iTGB, even when using a game loop, by converting a lot of game code over to C++.
#5
That does sound very reasssuring. I know small bits of C++ but i certainly am never going to be an expert (i would say very basic level knowledge of C++).
The first game i am developing is just a whack a mole type game, this is my proof of concept to test TGB and get something working over on the iphone/submitted etc. This is kinda the standard process i follow when making games on other platforms. So i document as i go along and have a good idea of what i need to do (its so easy to forget :D. Also it means further development is alot quicker.
The second game doesnt require any major graphics processing just access to certain device functions. At least the first 3-5 games do not require much heavy graphics processing at all.
But this is always the problem with developing something that you cannot see as such. I know that is the problem with all phone development, but hopefully the concerns are still valid.
Thanks for the very speedy replies. I am committed to this as recently got an Apple Mac and TGB, so I just need to make sure I dont mess anything up or misunderstand anything.
07/29/2009 (5:00 am)
Quote:The required knowledge in C++ for this task does not go much further than what you know from TorqueScript already, so its not like you must become a C++ master.
That does sound very reasssuring. I know small bits of C++ but i certainly am never going to be an expert (i would say very basic level knowledge of C++).
The first game i am developing is just a whack a mole type game, this is my proof of concept to test TGB and get something working over on the iphone/submitted etc. This is kinda the standard process i follow when making games on other platforms. So i document as i go along and have a good idea of what i need to do (its so easy to forget :D. Also it means further development is alot quicker.
The second game doesnt require any major graphics processing just access to certain device functions. At least the first 3-5 games do not require much heavy graphics processing at all.
But this is always the problem with developing something that you cannot see as such. I know that is the problem with all phone development, but hopefully the concerns are still valid.
Thanks for the very speedy replies. I am committed to this as recently got an Apple Mac and TGB, so I just need to make sure I dont mess anything up or misunderstand anything.
#6
It requires only very few behaviors, does not need physics and a lot of other things can be disabled too. You likely won't even need to enable the physics and just manually move the moles up and down in the scenegraph update or their own update if you don't want to enable the global update callback on the screengraph.
With a basic background in C++ you definitely have a good foundation to build upon. The most frightening part is already known to you due to that (pointers and how to handle them to clean allocated objects again). You should have very little problems understanding the relation between behaviors and components then :)
07/29/2009 (5:23 am)
A simple whack a mole could potentially even be able to get away fully script driven :)It requires only very few behaviors, does not need physics and a lot of other things can be disabled too. You likely won't even need to enable the physics and just manually move the moles up and down in the scenegraph update or their own update if you don't want to enable the global update callback on the screengraph.
With a basic background in C++ you definitely have a good foundation to build upon. The most frightening part is already known to you due to that (pointers and how to handle them to clean allocated objects again). You should have very little problems understanding the relation between behaviors and components then :)
#7
07/29/2009 (1:15 pm)
the iphone is not a PC, so a direct port with little to no modifications, you can expect that result (2 FPS). especially if your game has a lot of behaviors usage 
#8
This game was a fast-paced action game. Initially, I tried to treat iTGB like I would normally use TGB - all movements were done by altering the velocity of objects. By the time I got the game running on an actual iPhone, however, I saw my FPS was around 10fps. That wasn't gonna fly.
It was about this time I had to start programming AI. I knew that the AI cycles would nuke the device if I did it all in script. This is when I started working with components. All AI routines went into components, and (almost) all movements were changed from being velocity alterations, to moving the objects in real-time in that objects component based on its movement rules (IE: direction, speed, etc).
In the end, I found I had a solid set of rules to get this game to run very well on the iPhone...
1.) No physics. If it needs physics, then bypass iTGBs default physics and write my own localized, math-light routines, that were local to that object, built into its component.
2.) If it is an operation that will occur more than once per second, then it must be in C++. (The ONLY time I broke this rule, was anywhere that an object dependency was needed. No matter what, I was unable to fix iTGBs object dependency on level load crash, so I just removed them all, and do all my object dependency information gathering in script).
In the end, I'd say about 85% of this game is script driven. Only the in-depth operations were done in C++. The final framerate on my iPhone 3G averages at 25fps, and is over 30-35fps on the iPod Touch.
Now that I've gone through the entire dev cycle of a large-scale game using iTGB, I'd love to begin another large-scale iTGB project where I can take everything I learned and start with those in my initial code design, rather than altering my code as I learn.
In the end, I'd say iTGB is an awesome engine, and it is fully capable of doing very complex games on the iPhone. Yes, you do need to understand the breakdown of TorqueScript vs. C++ - but the real trick as I said above is if the operation is very frequent, put it in C++ - otherwise script is fine.
A bit long winded, but that's my 2-cents on the matter. Hopefully I'll get to do a review or something when this game is finished and I'll then be able to go really in-depth into things I did to make sure the game ran awesome.
07/29/2009 (1:31 pm)
I can't talk too much about the game I'm finishing up as it's under NDA for a contract, but I can go into a LITTLE detail of the stuff we had to do. Once the game is released I'd be happy to go into a lot more detail, however.This game was a fast-paced action game. Initially, I tried to treat iTGB like I would normally use TGB - all movements were done by altering the velocity of objects. By the time I got the game running on an actual iPhone, however, I saw my FPS was around 10fps. That wasn't gonna fly.
It was about this time I had to start programming AI. I knew that the AI cycles would nuke the device if I did it all in script. This is when I started working with components. All AI routines went into components, and (almost) all movements were changed from being velocity alterations, to moving the objects in real-time in that objects component based on its movement rules (IE: direction, speed, etc).
In the end, I found I had a solid set of rules to get this game to run very well on the iPhone...
1.) No physics. If it needs physics, then bypass iTGBs default physics and write my own localized, math-light routines, that were local to that object, built into its component.
2.) If it is an operation that will occur more than once per second, then it must be in C++. (The ONLY time I broke this rule, was anywhere that an object dependency was needed. No matter what, I was unable to fix iTGBs object dependency on level load crash, so I just removed them all, and do all my object dependency information gathering in script).
In the end, I'd say about 85% of this game is script driven. Only the in-depth operations were done in C++. The final framerate on my iPhone 3G averages at 25fps, and is over 30-35fps on the iPod Touch.
Now that I've gone through the entire dev cycle of a large-scale game using iTGB, I'd love to begin another large-scale iTGB project where I can take everything I learned and start with those in my initial code design, rather than altering my code as I learn.
In the end, I'd say iTGB is an awesome engine, and it is fully capable of doing very complex games on the iPhone. Yes, you do need to understand the breakdown of TorqueScript vs. C++ - but the real trick as I said above is if the operation is very frequent, put it in C++ - otherwise script is fine.
A bit long winded, but that's my 2-cents on the matter. Hopefully I'll get to do a review or something when this game is finished and I'll then be able to go really in-depth into things I did to make sure the game ran awesome.
#9
1) is the reason I've been and will again be investing time to support VFP in iTGB for at very least the Vector - Matrix ops.
Anything that helps me getting stuff from the CPU is a good thing and after all the 3GS, the only device having problem with it (as the VFP was replaced with NEON), has a different CPU so its possible to detect if it is a 3GS or newer or not and use the regular calcs or VFP depending on that.
Generally the first step here, if you didn't do that already, is adding the following two flags to your project: -marm -ffast-math
07/29/2009 (3:55 pm)
Thank you for the overview on the experience you made :)1) is the reason I've been and will again be investing time to support VFP in iTGB for at very least the Vector - Matrix ops.
Anything that helps me getting stuff from the CPU is a good thing and after all the 3GS, the only device having problem with it (as the VFP was replaced with NEON), has a different CPU so its possible to detect if it is a 3GS or newer or not and use the regular calcs or VFP depending on that.
Generally the first step here, if you didn't do that already, is adding the following two flags to your project: -marm -ffast-math
#10
07/29/2009 (6:31 pm)
Stickying this thread for a bit so other users can read the tips posted by developers who have shipped iPhone games using the engine 
#11
Also, where you say
"No matter what, I was unable to fix iTGBs object dependency on level load crash, so I just removed them all, and do all my object dependency information gathering in script"
Could you explain that a little more please? I'm not sure but is this problem you dealt with the same one a lot of us are having with 1.2? I.e. that it crashes after 10-20 minutes no matter what. Because that really needs to be solved one way or another (and since 1.3 is not out yet I'm looking for other solutions).
09/05/2009 (7:37 am)
Is their any forum post, or documentation where we can see some examples of torque script redone as C++? Not for everything, just for those occasions like Dave mentioned; It would be a real help if someone could explain this a little more since it seems like everyone is going to have to do some Torque to Script modification to get their game to run (At least with 1.2). Also, where you say
"No matter what, I was unable to fix iTGBs object dependency on level load crash, so I just removed them all, and do all my object dependency information gathering in script"
Could you explain that a little more please? I'm not sure but is this problem you dealt with the same one a lot of us are having with 1.2? I.e. that it crashes after 10-20 minutes no matter what. Because that really needs to be solved one way or another (and since 1.3 is not out yet I'm looking for other solutions).
#12
I am at PAX right now (waiting for a panel to start as I write this, actually). I'll post a Full coherent response with some examples when I get home, just don't let me forget :)
09/05/2009 (8:55 am)
I can run my game for hours without it crashing, so that very well may fix it. All um doing is setting global variables in script and reading them in the engine level. That prevents a lot of crashes.I am at PAX right now (waiting for a panel to start as I write this, actually). I'll post a Full coherent response with some examples when I get home, just don't let me forget :)
#13
Anyway, yah a fairly easy to understand explanation along with examples would be grand, because I've had little luck dealing with it on my own and its pretty frustrating.
Looking forward to your response, and I hope you have a awesome time at PAX.
EDIT:
I'm taking a look at the "FIXED: GDB: Program received signal: "0" & Memory Leak (iTGB 1.2)" forum thread to see if this actually might be the solution, since it sounds exactly like my problem.
DOUBLE EDIT:
Holy #$%!. It did. Awesome. Still though, examples of Torque Script to C++ would still be helpful (Although it is running nicely with the fix).
09/05/2009 (12:51 pm)
Ah you lucky son of a gun, my brothers at PAX too; wish I was.Anyway, yah a fairly easy to understand explanation along with examples would be grand, because I've had little luck dealing with it on my own and its pretty frustrating.
Looking forward to your response, and I hope you have a awesome time at PAX.
EDIT:
I'm taking a look at the "FIXED: GDB: Program received signal: "0" & Memory Leak (iTGB 1.2)" forum thread to see if this actually might be the solution, since it sounds exactly like my problem.
DOUBLE EDIT:
Holy #$%!. It did. Awesome. Still though, examples of Torque Script to C++ would still be helpful (Although it is running nicely with the fix).
#14
%this.owner.getPosition();
In C++ it would just be...
object->getPosition();
And in reality, you don't even need components... they just make it easier based on your needs.
Anyway... more to come when my brain != mush.
PS: Dillon: What parts of the Memory Leak thread did you get to work? I tried everything there and it actually broke my game further! I'd love to hear what you did as the stuff there seems quite good!
09/10/2009 (8:43 am)
Hey guys... I haven't forgotten about you. I'm on the Unlucky List of people from PAX who got swine flu. I've been sleeping since Sunday (quite literally). Putting in a few hours of work today, though I'm getting exhausted pretty quickly. Gonna be crashing again soon. I'll tell ya... I've been WAY sicker before, but this is the first flu to literally knock me out for the better part of a week. As soon as I can think clearly, I'll do a real nice tutorial on TorqueScript to C++. It's generally pretty simple though.... almost all console commands feed into C++ code. So all you really need to do is created a bunch of components for your objects, then call the script commands through the component. So if in TorqueScript you would do...%this.owner.getPosition();
In C++ it would just be...
object->getPosition();
And in reality, you don't even need components... they just make it easier based on your needs.
Anyway... more to come when my brain != mush.
PS: Dillon: What parts of the Memory Leak thread did you get to work? I tried everything there and it actually broke my game further! I'd love to hear what you did as the stuff there seems quite good!
#15
The game I'm working on is super laggy and I'm serious about porting some of my script to C++. Can you give me some tips for getting started with this?
10/27/2009 (4:53 pm)
Dave, are you still alive? I hope so, swine flu is brutal from what I hear.The game I'm working on is super laggy and I'm serious about porting some of my script to C++. Can you give me some tips for getting started with this?
#16
Yes - I am finally alive again! My apologies, I believe this thread slipped through the cracks with everything that happened during my illness.
So, the best way to get started is by determining what parts of your game are the laggiest, and what specifically is causing that lag. So before you do any code, check the following....
- Do you have a lot of objects in the game world that are enabled at any one time?
- Area you using physics? If so, is it needed?
- Are your graphics small and optimized?
- Are you unloading ALL resources when they are not needed?
- Are you constantly running any command more than once per second?
- Are you constantly loading and unloading any graphics or sounds?
- Are you frequently having new objects created in the world rather than dynamically repurposing existing objects?
Check those, and we'll go from there. :)
10/27/2009 (5:17 pm)
Peter,Yes - I am finally alive again! My apologies, I believe this thread slipped through the cracks with everything that happened during my illness.
So, the best way to get started is by determining what parts of your game are the laggiest, and what specifically is causing that lag. So before you do any code, check the following....
- Do you have a lot of objects in the game world that are enabled at any one time?
- Area you using physics? If so, is it needed?
- Are your graphics small and optimized?
- Are you unloading ALL resources when they are not needed?
- Are you constantly running any command more than once per second?
- Are you constantly loading and unloading any graphics or sounds?
- Are you frequently having new objects created in the world rather than dynamically repurposing existing objects?
Check those, and we'll go from there. :)
#17
Thanks for getting back to me.
I'm developing a labyrinth style game like this one:
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=284571899&mt=8
- I'm using a tile layer to design the maze walls for each level (80x120 with 8x8 pixel tiles). I'm beginning to think this tile layer is way too big since the frame rate improves considerably when I remove it.
- The only objects that use physics are the marble and the tile layer.
- How do I unload resources in torquescript?
- I'm not running any commands more than once per second - unless collision callbacks count?
- I'm using this audio engine to load my sound sounds dynamically.
http://tdn.garagegames.com/wiki/TGB/MiniTutorials/Super_Simple_Audio
- The tile layer is the only object that is created dynamically.
- My game also crashes whenever I load a new level. Maybe I need to unload stuff first?
Thanks for your help Dave.
10/29/2009 (6:09 pm)
Hi Dave,Thanks for getting back to me.
I'm developing a labyrinth style game like this one:
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=284571899&mt=8
- I'm using a tile layer to design the maze walls for each level (80x120 with 8x8 pixel tiles). I'm beginning to think this tile layer is way too big since the frame rate improves considerably when I remove it.
- The only objects that use physics are the marble and the tile layer.
- How do I unload resources in torquescript?
- I'm not running any commands more than once per second - unless collision callbacks count?
- I'm using this audio engine to load my sound sounds dynamically.
http://tdn.garagegames.com/wiki/TGB/MiniTutorials/Super_Simple_Audio
- The tile layer is the only object that is created dynamically.
- My game also crashes whenever I load a new level. Maybe I need to unload stuff first?
Thanks for your help Dave.
#18
11/18/2009 (11:25 am)
Very interested in the optimizations examples. I have this thread noted to follow.
#19
First off, I've found tilemaps to have huge problems in iTGB. From what I have found, every single tile attempts to receive physics, even if physics are shut off. So as a result, your performance is obliterated. You should either avoid using tilemaps, or look into fixing the performance problems with them.
Unloading resources in TorqueScript is easy! myDatablock.delete(); :)
Don't use collisions! iTGB's default collision system is VERY performance intensive and was never meant for the iPhone. I suggest writing your own engine-level system that is meant to do exactly what is needed for your game.
Loading and unloading problems is a bug in the engine. Instead of doing that, just load one level, then dynamically repopulate it with what's needed.
11/20/2009 (4:43 am)
Peter,First off, I've found tilemaps to have huge problems in iTGB. From what I have found, every single tile attempts to receive physics, even if physics are shut off. So as a result, your performance is obliterated. You should either avoid using tilemaps, or look into fixing the performance problems with them.
Unloading resources in TorqueScript is easy! myDatablock.delete(); :)
Don't use collisions! iTGB's default collision system is VERY performance intensive and was never meant for the iPhone. I suggest writing your own engine-level system that is meant to do exactly what is needed for your game.
Loading and unloading problems is a bug in the engine. Instead of doing that, just load one level, then dynamically repopulate it with what's needed.
Torque 3D Owner Kenneth Holst
Default Studio Name
Can you describe a little, the type of game you are looking to create? Michael Perry is our local expert on iTG(X) and might be able to help share some information as well, if he happens to get a chance.