How many files must an app cut down, before it's allowed to be slim?
by Zilla · in iTorque 2D · 08/24/2009 (10:34 am) · 4 replies
Like every iPhone developer, I want to have an app that is as small and fast as possible.
Attention, nOObish questions:
When you create a new game in (i)TGB, the common directory is created and it is full of (DSO)-files.
Will they all find their way to the compiled app, regardless if my app needs them or not?
(e.g. in C I would use #include...) Though the common folder is totally under 1MB...
What can I do/delete to make my app slim?
What can I do make my app start fast?
e.g.
Will it load faster if I set preload = false in the AudioProfiles?
Will it load faster if I uncheck Preload in the Image Settings?

Are there other possibilities?
Attention, nOObish questions:
When you create a new game in (i)TGB, the common directory is created and it is full of (DSO)-files.
Will they all find their way to the compiled app, regardless if my app needs them or not?
(e.g. in C I would use #include...) Though the common folder is totally under 1MB...
What can I do/delete to make my app slim?
What can I do make my app start fast?
e.g.
Will it load faster if I set preload = false in the AudioProfiles?
new AudioProfile(MyAudioProfile)
{
filename = "~/data/audio/myaudio.wav";
description = "AudioNonLooping";
preload = true;
};Will it load faster if I uncheck Preload in the Image Settings?

Are there other possibilities?
#2
Did I get this right?:
08/24/2009 (1:03 pm)
Thank you very much for your detailed answer :)Did I get this right?:
Quote:It can load faster when you check preloadThe app will load faster, if I preload all my graphics?
#3
08/24/2009 (1:26 pm)
preload will load everything at application start time, which will slow down your application during startup but make it run faster during play.
#4
08/24/2009 (4:14 pm)
You could combine preload with scripts you don't load until a certain level, too. Then the graphics load before level start, and you avoid hitches because of mid-level loading. Experimentation is needed for each case :)
Torque 3D Owner Ronny Bangsund
Torque Cheerleaders
You get all the DSOs in the built directory. Remove anything you don't need. There are mouse pointers in the common/ folder, and you might never use those. Remove any related scripts and graphics, for example. I've seen common/ folders half the size of the supplied one.
(On my wish list:Command-line script compiler target which you can customise with the same additions you make in your game project, and make part of the Xcode build process. I could probably hack one up.)
Code hacking:
There are probably many small bits you can remove. If you're not using networking, there are still calls being made to parts of the code (including some threading-related stuff which kills performance). Search for "Net::init()" in the project. Start slicing out code :)
There's also a thread about using Chipmunk for physics. Massive framerate improvement. Wishing for a simple to use resource.
Converting scripts to engine code is another classic speedup method. Loops and calculations are the prime candidates, and possibly many scripts spanning more than a page per function.
Then you have the still forthcoming 1.3 release... we want that now :)
Untried and uncertain:
iPhone 3GS uses a different processor with a different type of maths unit. If you look in the Xcode project's build settings, you'll see that the newer SDKs set up for armv6 and arm7. What it means is that it uses code which *works* on both, not code which *works well*. If you choose an optimised build, you actually get a universal ARM binary with a separate armv7 codepath and optimised floating point code. However, Apple seem to reject this for apps which don't target OS 3.0 minimum. UB apps seem to work on 2.x, but Apple won't allow them there.
(Stats so far seem to have 3.0 adoption rates at 75% of all devices. It might be less.)