iTGB Cheat Sheet (updated 2-25)
by Mat Valadez · in iTorque 2D · 01/20/2009 (1:03 pm) · 36 replies
Here's a list of handy things to remember when developing with iTGB
Update(02-11): Added links to code additions at the bottom
Update(02-14): Added important safety tip for multiTouch
Update(02-25): Added important safety tip for PUAP_SCRIPT_CHANGE
Preprocessor commands
PUAP_OPTIMIZE enables the following iPhone optimizations;
t2dSceneObjects now have a setUsesPhysics(bool) function that allows them to use physics or not. All object are false by default, which helps to reduce wasting time processing physics on non-moving objects
also affected:
t2dParticleEffects will stop playing when their world limit is off-screen
t2dSceneObject mCollisionMaxIterations is set to 1 by default
PUAP_SCRIPT_CHANGE activates a few changes to the scripting engine. The big benefit of this is that script execution is much quicker, in particular, variable lookup is faster than without it. When this is defined, iTGB will change the way it reads/compiles scripts, this means that DSOs will be incompatible with previous versions, and old DSOs will be incompatible with iTGB. Because of this, it's best to use scripts that have been compiled with the same binary to ensure compatibility.
Important SafeTy Tip With this flag set, you must initialize your variables or you may get some bogus values. i.e. use this:
USE_COMPONENTS adds some functionality to the TGB components system that allow them to receive onUpdate() and onAddToScene() callbacks, like the script behaviors do.
With this undefined, components still work, but will not receive those callbacks, this define is there to improve script->code conversion.
iPhone-specific features
MultiTouch
The first touch is always mapped to the mouse/cursor. If your game does not use multi-touch(example: a port of a PC mouse-driven point 'n click), you wan't have to implement any touch callbacks.
When multiTouch is enabled(using a global variable), touches are handled by script callbacks.
Important Safety Tip: Don't forget to set
$pref::iPhone::enableMultipleTouch = true;
in defaultPrefs.cs
All touches (including the first one) are passed to three functions
%touchCount is the number of touches for this event, %touchX is a list of the touchs X value, %touchy is a list of the touches Y value. Example:
Accelerometer
The accelerometer is mapped to joystick0 three axises (xaxis, yaxis and zaxis) and can be mapped as you would a joystick in TGB. Example:
UPDATE 1-23-09
By default, iTGB will disable all text output to speed things up, to turn that off for debugging, call this function:
Images
iTGB supports PVR images. To create a PVR texture from a PNG or another filetype use the
PVR tool. PVRs must be square and power of 2 (e.g. 512x512 pixels). iTGB will look for PVR images first, so, when specifying an image (such as the "bitmap" parameter in a GUI), leave out the extension of the file and iTGB will find the image for you, looking for PVRs first.
$Global Variables
iTGB will force all palleted BMPs to 16 bit if you specify
$pref::iPhone::ForcePalletedBMPsTo16Bit = true
this can save on video memory if you need it.
iTGB will shutdown the network, allowing the game to run faster by not running unused Net code if
$pref::iPhone::UsesNetwork = false in defaultpref.cs
The following need to be set in DefaultPrefs.cs for their changes to load when iTGB does:
$pref::iPhone::StatusBarType ("BlackTransparent"/"BlackOpaque")
$pref::iPhone::StatusBarHidden (true/false)
$pref::iPhone::ScreenOrientation ("Portrait"/"Landscape")
$pref::iPhone::ScreenAutoRotate (true/false)
$pref::iPhone::EnableMultipleTouch (true/false)
General Things To Know
iTGB on Simulator or device will only read DSOs, you don't even need to have the .cs files present on the device. Make sure your scripts are compiled before trying to run.
In order to transfer you game content to you app bundle, you need to include the following in your Xcode project's "Resources" folder;
common folder
game folder
Any other mod folders you are using
main.cs
default.png
Common and game should contain your script DSOs, main.cs is the only file that need not be compiled(main.cs.dso is not loaded, only the cs file)
default.png is the image the iPhone will display while your app(iTGB) is starting up
When you add these items to the XCode project, make sure to select the second option for adding folders(recursively add folders) The icons will be blue in the XCode sideBar if you added them correctly.
XCode will not automatically transfer your changed files if you modfiy them. The best way to make sure that it does is to delete the the .app in your XCode project's build directory, then build. This will not re-compile your project, but it will force XCode to copy all of your resources over.
UPDATE 02-11-09
Code additions from forum members
For those having a problem with iTGB crashing when the home button is pressed: Quit Fix
How to get a Unique identifier for a device in script(Credit to Dave Young) Device ID ConsoleFunction
How to get device real-world location(Credit to Dave Young) Device Location
An implementation of the iPhone keyboard: Keyboard
Updates will come when I think of them. :p
Update(02-11): Added links to code additions at the bottom
Update(02-14): Added important safety tip for multiTouch
Update(02-25): Added important safety tip for PUAP_SCRIPT_CHANGE
Preprocessor commands
PUAP_OPTIMIZE enables the following iPhone optimizations;
t2dSceneObjects now have a setUsesPhysics(bool) function that allows them to use physics or not. All object are false by default, which helps to reduce wasting time processing physics on non-moving objects
also affected:
t2dParticleEffects will stop playing when their world limit is off-screen
t2dSceneObject mCollisionMaxIterations is set to 1 by default
PUAP_SCRIPT_CHANGE activates a few changes to the scripting engine. The big benefit of this is that script execution is much quicker, in particular, variable lookup is faster than without it. When this is defined, iTGB will change the way it reads/compiles scripts, this means that DSOs will be incompatible with previous versions, and old DSOs will be incompatible with iTGB. Because of this, it's best to use scripts that have been compiled with the same binary to ensure compatibility.
Important SafeTy Tip With this flag set, you must initialize your variables or you may get some bogus values. i.e. use this:
function countTo( %input ) {
%count = "";//or %count == 0;
while( %count < %input {
echo( "current count:" SPC %count );
%count++;
}
}instead of this:function countTo( %input ) {
while( %count < %input {
echo( "current count:" SPC %count );
%count++;
}
}USE_COMPONENTS adds some functionality to the TGB components system that allow them to receive onUpdate() and onAddToScene() callbacks, like the script behaviors do.
With this undefined, components still work, but will not receive those callbacks, this define is there to improve script->code conversion.
iPhone-specific features
MultiTouch
The first touch is always mapped to the mouse/cursor. If your game does not use multi-touch(example: a port of a PC mouse-driven point 'n click), you wan't have to implement any touch callbacks.
When multiTouch is enabled(using a global variable), touches are handled by script callbacks.
Important Safety Tip: Don't forget to set
$pref::iPhone::enableMultipleTouch = true;
in defaultPrefs.cs
All touches (including the first one) are passed to three functions
oniPhoneTouchUp( %touchCount, %touchX, %touchY ) oniPhoneTouchDown( %touchCount, %touchX, %touchY ) oniPhoneTouchMove( %touchCount, %touchX, %touchY )The parameters for each function work the same.
%touchCount is the number of touches for this event, %touchX is a list of the touchs X value, %touchy is a list of the touches Y value. Example:
getWord( %touchX, %touchCount );will give you the X value for the last touch.
Accelerometer
The accelerometer is mapped to joystick0 three axises (xaxis, yaxis and zaxis) and can be mapped as you would a joystick in TGB. Example:
moveMap.bind(joystick0, xaxis, "joystickMoveX" );
moveMap.bind(joystick0, yaxis, "joystickMoveY" );
moveMap.bind(joystick0, Zaxis, "joystickMoveZ" );UPDATE 1-23-09
By default, iTGB will disable all text output to speed things up, to turn that off for debugging, call this function:
enableDebugOutput( true );This will output all the console text to your XCode GBD output pane. In other words, everything that yo would normally see in the Torsion output and the console.log will be visible through XCode
Images
iTGB supports PVR images. To create a PVR texture from a PNG or another filetype use the
PVR tool. PVRs must be square and power of 2 (e.g. 512x512 pixels). iTGB will look for PVR images first, so, when specifying an image (such as the "bitmap" parameter in a GUI), leave out the extension of the file and iTGB will find the image for you, looking for PVRs first.
$Global Variables
iTGB will force all palleted BMPs to 16 bit if you specify
$pref::iPhone::ForcePalletedBMPsTo16Bit = true
this can save on video memory if you need it.
iTGB will shutdown the network, allowing the game to run faster by not running unused Net code if
$pref::iPhone::UsesNetwork = false in defaultpref.cs
The following need to be set in DefaultPrefs.cs for their changes to load when iTGB does:
$pref::iPhone::StatusBarType ("BlackTransparent"/"BlackOpaque")
$pref::iPhone::StatusBarHidden (true/false)
$pref::iPhone::ScreenOrientation ("Portrait"/"Landscape")
$pref::iPhone::ScreenAutoRotate (true/false)
$pref::iPhone::EnableMultipleTouch (true/false)
General Things To Know
iTGB on Simulator or device will only read DSOs, you don't even need to have the .cs files present on the device. Make sure your scripts are compiled before trying to run.
In order to transfer you game content to you app bundle, you need to include the following in your Xcode project's "Resources" folder;
common folder
game folder
Any other mod folders you are using
main.cs
default.png
Common and game should contain your script DSOs, main.cs is the only file that need not be compiled(main.cs.dso is not loaded, only the cs file)
default.png is the image the iPhone will display while your app(iTGB) is starting up
When you add these items to the XCode project, make sure to select the second option for adding folders(recursively add folders) The icons will be blue in the XCode sideBar if you added them correctly.
XCode will not automatically transfer your changed files if you modfiy them. The best way to make sure that it does is to delete the the .app in your XCode project's build directory, then build. This will not re-compile your project, but it will force XCode to copy all of your resources over.
UPDATE 02-11-09
Code additions from forum members
For those having a problem with iTGB crashing when the home button is pressed: Quit Fix
How to get a Unique identifier for a device in script(Credit to Dave Young) Device ID ConsoleFunction
How to get device real-world location(Credit to Dave Young) Device Location
An implementation of the iPhone keyboard: Keyboard
Updates will come when I think of them. :p
#2
01/22/2009 (6:36 am)
Great cheat sheet, thanks!
#3
01/27/2009 (5:48 am)
Mat, thank you very much for the 'update dso' tip. It works like a charm and saves BUNDLES of time.
#4
"$pref::iPhone::ForcePalletedBMPsTo16Bit"
"PUAP_OPTIMIZE"
"PUAP_SCRIPT_CHANGE"
will make their way into iTGE?
Thanks!
02/04/2009 (1:00 am)
Mat, any idea on when some of those features, namely:"$pref::iPhone::ForcePalletedBMPsTo16Bit"
"PUAP_OPTIMIZE"
"PUAP_SCRIPT_CHANGE"
will make their way into iTGE?
Thanks!
#5
02/15/2009 (3:53 pm)
I don't know of any plans for those, as most of those improvements there are iTGB specific, particularly PUAP_OPTIMIZE. Also, since TGE doesn't rely as heavily on script, the script change won't have as dramatic an effect, nor would it even be so nescessary. iTGE is coming along rather well on it's own though.
#6
This seems to be a false statement (maybe partially true). If I don't include .cs files (besides the root main.cs) things are pretty whacked out in my game; it seems some things are fine but most isn't.
Under what conditions is this statement actually true? I'd rather not package my .cs files in my application but at the moment I have no choice but to do so.
Thanks!
02/18/2009 (6:37 pm)
"iTGB on Simulator or device will only read DSOs, you don't even need to have the .cs files present on the device. Make sure your scripts are compiled before trying to run."This seems to be a false statement (maybe partially true). If I don't include .cs files (besides the root main.cs) things are pretty whacked out in my game; it seems some things are fine but most isn't.
Under what conditions is this statement actually true? I'd rather not package my .cs files in my application but at the moment I have no choice but to do so.
Thanks!
#7
If DSOs are present iTGB will ignore the cs files, and if DSOs are not present, there should be an error along with the filename. Check your console output.
02/18/2009 (8:25 pm)
What kind of behavior are you getting without the cs files?If DSOs are present iTGB will ignore the cs files, and if DSOs are not present, there should be an error along with the filename. Check your console output.
#8
Good one. Instruct me on how to hit the ~ key on the iPhone while the game is running :)
02/18/2009 (8:27 pm)
"Check your console output."Good one. Instruct me on how to hit the ~ key on the iPhone while the game is running :)
#9
Just make sure to call enableDebugOutput( true ); first, preferably in in main.cs
02/18/2009 (8:57 pm)
No, using XCode, look at the GDB output :)Just make sure to call enableDebugOutput( true ); first, preferably in in main.cs
#10
I got that GDB output going.
Unfortunately, it yields no errors at all in both cases: (1) I don't include the .cs files and (2) when I do. I get almost identical output.
The only warnings I'm getting (in both cases) is:
t2dPhysics::setCollisionPolyCustom() - Polygon is not convex! Defaulting to Quad! ()
Could not locate texture: game/data/images/menu/btn-play_i
(the polygon one I'm still confused about...likely unrelated to this though...something to do with the path layer that I'm using for A* pathing; and the texture one I don't care about...I'm not going to package 4 different versions of my gui graphics just to get the warnings to go away.)
The only inconsistency from the two different outputs is when I include the .cs files, I get more of those "Defaulting to Quad" messages. No errors whatsoever in either case about not being able to find this file or that file.
So at the moment I'm at a loss. What I'm seeing in my game when I do not include the .cs files is that numerous objects are not being created in my levels (many graphics, et. al.).
02/19/2009 (5:57 pm)
Hi Mat,I got that GDB output going.
Unfortunately, it yields no errors at all in both cases: (1) I don't include the .cs files and (2) when I do. I get almost identical output.
The only warnings I'm getting (in both cases) is:
t2dPhysics::setCollisionPolyCustom() - Polygon is not convex! Defaulting to Quad! ()
Could not locate texture: game/data/images/menu/btn-play_i
(the polygon one I'm still confused about...likely unrelated to this though...something to do with the path layer that I'm using for A* pathing; and the texture one I don't care about...I'm not going to package 4 different versions of my gui graphics just to get the warnings to go away.)
The only inconsistency from the two different outputs is when I include the .cs files, I get more of those "Defaulting to Quad" messages. No errors whatsoever in either case about not being able to find this file or that file.
So at the moment I'm at a loss. What I'm seeing in my game when I do not include the .cs files is that numerous objects are not being created in my levels (many graphics, et. al.).
#11
To clear the air, I went ahead and eliminated that "Defaulting to Quad" warning entirely just to make sure it had nothing to do with this.
It doesn't. I still have to include all my .cs files.
02/19/2009 (6:12 pm)
Edit:To clear the air, I went ahead and eliminated that "Defaulting to Quad" warning entirely just to make sure it had nothing to do with this.
It doesn't. I still have to include all my .cs files.
#12
Add "gameScripts/datablocks.cs" to your list of files that you must include in your build.
So main.cs isn't the only one you need to keep. Including gameScripts/datablocks.cs solved my issue.
-Ray
02/22/2009 (3:02 pm)
Mat,Add "gameScripts/datablocks.cs" to your list of files that you must include in your build.
So main.cs isn't the only one you need to keep. Including gameScripts/datablocks.cs solved my issue.
-Ray
#13
Try one of the demos and see if you can get those to work without having to include cs files. There may just be something about your project, maybe datablocks.cs isn't compiling and your using an old one or something.
Also, make sure your build settings (particulary PUAP_SCRIPT_CHANGE) are the same for your iPhone build, and the build you are compiling your scripts with.
02/23/2009 (10:35 am)
That's pretty strange really, There's nothing "special" about that cs file in source, it is just exec()'ed same as everything else (whereas main.cs does go through a completely different code path)%userDatablockFile = expandFilename("game/gameScripts/datablocks.cs");
...
addResPath( %userDatablockFile );
if( isFile( %userDatablockFile ) )
exec( %userDatablockFile );Taken from iPhone BehaviorShooter projectManageMent.csTry one of the demos and see if you can get those to work without having to include cs files. There may just be something about your project, maybe datablocks.cs isn't compiling and your using an old one or something.
Also, make sure your build settings (particulary PUAP_SCRIPT_CHANGE) are the same for your iPhone build, and the build you are compiling your scripts with.
#14
03/13/2009 (10:15 am)
can we add the issue with custom fonts? if you want a font you need to copy it manually into your build folder.
#15
Slow:
Faster:
03/16/2009 (8:48 am)
One might want to add general script optimization tips. For example, a decrementing do-while loop is significantly faster than an incrementing for loop.Slow:
for(%i = 0; %i < 10; %i++)
{
...
}Faster:
%i = 10;
do
{
%i--;
...
}while(%i > 0)
#16
Optimally the next iTGB release has this integrated as working directory for the file commands
05/02/2009 (7:22 pm)
Getting the writable documents directory on the iPhone with Obj-C:// Get documents directory NSArray *arrayPaths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSFileManager *fileManager = [NSFileManager defaultManager]; NSError *error; NSString *docDir = [arrayPaths objectAtIndex:0]; NSString *writablePath = [docDir stringByAppendingPathComponent:@"TestCase.txt"];
Optimally the next iTGB release has this integrated as working directory for the file commands
#17
05/03/2009 (7:39 pm)
Why is decrementing a do-while loop faster than a for loop? Does this apply to torquescript generally or only to iTGB?
#18
www.garagegames.com/community/resources/view/17153
05/05/2009 (3:01 pm)
I've just added a resource about saving and loading data on the iPod Touch / iPhone, which could be a nice addon to this cheat sheet:www.garagegames.com/community/resources/view/17153
#19
It applies to C++, Javascript, TorqueScript, and more. Honestly, I can't remember where I picked that up. (EDIT: With that said, I have tested this many times and seen much success.) Even faster should be this:
I know there are two parts to it. First, putting the condition at the end can save time, since in a do-loop you always execute at least once without checking the condition. In a for-loop, you always check once... then check again to kill the loop. Second, you're reducing the amount of low-level copying that goes on to process the increment.
There's probably more to it than that. But it works great if you've got a section of code that is repeatedly called.
05/05/2009 (3:44 pm)
Quote:
Why is decrementing a do-while loop faster than a for loop? Does this apply to torquescript generally or only to iTGB?
It applies to C++, Javascript, TorqueScript, and more. Honestly, I can't remember where I picked that up. (EDIT: With that said, I have tested this many times and seen much success.) Even faster should be this:
%i = 10;
do
{
...
}while(%i--)I know there are two parts to it. First, putting the condition at the end can save time, since in a do-loop you always execute at least once without checking the condition. In a for-loop, you always check once... then check again to kill the loop. Second, you're reducing the amount of low-level copying that goes on to process the increment.
There's probably more to it than that. But it works great if you've got a section of code that is repeatedly called.
#20
I have no idea where you picked it up either as it's sadly utter tosh!
The compiler will 9/10 store the incrementer for a for loop in registers. This is faster than the store and retrieve method used by while loops (yes I have actually written a compiler before). The speed of a loop is more determined by the actual condition the loop is operating on AND more importantly the contents of the loop, than anything else.
Unless you have actually written the compiler that is converting your code into low level assembly, you can't say which loop will run faster. I doubt anyone who has programmed for a few years will agree to support one type of loop over another without seeing your code and what it compiles down to!
05/05/2009 (4:03 pm)
@Chris I have no idea where you picked it up either as it's sadly utter tosh!
The compiler will 9/10 store the incrementer for a for loop in registers. This is faster than the store and retrieve method used by while loops (yes I have actually written a compiler before). The speed of a loop is more determined by the actual condition the loop is operating on AND more importantly the contents of the loop, than anything else.
Unless you have actually written the compiler that is converting your code into low level assembly, you can't say which loop will run faster. I doubt anyone who has programmed for a few years will agree to support one type of loop over another without seeing your code and what it compiles down to!
Torque Owner Warthog
Crude Games, LLC