Loading Time. Cmon Now!

#1 I'm considering integrating lzip in various ways. I just need to make some test programs and compare decompression times against the gzip format. The space savings are pretty good if you hack up a PNG format with it.

I also think fewer files with more data will help. Scripts, maybe not all that much, but graphics definitely.

#2 I do agree the load time is a little slow. I think the iTGB logo stays up for 5 seconds, then any time after that is load time? Or does iTGB load while displaying the logo? My current app is at about 8.5 seconds loading time.

#3 No, while the initial logo shows, nothing but the app code itself is loaded, so no game data etc

#4 Chris, 8.5 secs?! Wow... Did you do heavy modifications to the common/etc folders, or remove classes from the engine? I'm testing on clean stock iPod 2G and iPhone 3G.

I even moved the network startup to after the title screen and it barely budged the load time.

#5 Ya, almost exactly 8.5 seconds standalone launch. It's 12 seconds if I'm using the debugger. So 5 seconds of iTGB logo and 3.5 seconds of additional load time.

I'm not sure I'm doing anything different than you. Everything is on-demand. So all exec calls, all datablock creations, etc, are only done right when needed. I actually added classes to the TGB engine to support my shogi AI. I did remove all .cs and .gui files. All .utf that were not needed were removed. Script is fairly small. Most of the game is in C++. No image compression as framerate isn't an issue in a board game.

I honestly would prefer exactly 5 seconds. But I think given I have about 6 MB of Wav sounds, I don't think that's possible. The theme song is 5.6 MB by itself.

#6 The most important thing is definitely the datablock creation.
Do level based datablock execution. Don't execute what you don't need as each datablock execution means a processing of sound and/or texture

#7 I don't do any datablock execing at all until after the main menu loads, then it's all on demand, including the GUIs.

Still staring at the iTGB startup screen. I'm compiling for Device release also. I will see if there are frameworks included that aren't needed next.

#8 The only way I found to significantly reduce load time was to reduce the size and number of my assets. I was able to go from 16-18 second start up to about 8.5 seconds. Since the engine alone will take up to 4 seconds without any content, I think 8-10 seconds is fine. Though, Monster Truck Nitro, made with Unity, loads in 3-6 seconds on my device, but then it takes 5 or so seconds to load each level.

#9 I would completely understand the assets loading. Unfortunately this is all engine loading for me. I'm delaying asset and gui loading (except for the title screen) until after the title loads.

My next steps are going to be trimming stuff I didn't need out of the engine.

#10 wait for 1.2 <-- punchline

#11 I removed over 100 files from the engine and shaved the loading time down 1.5 secs or so.

Now on iPhone my quickest load time is 16.2 seconds, pre-gui or any datablock, game script, or sound file loading.

on the touch it's around 11-12 seconds

#12 This is part of the new 1.2, but here's a way to reduce the datablock load times (at the expense a feature I bet none of you use :) )

in t2dImageMapDatablock.cc, around line 425 change the function "bool t2dImageMapDatablock::compileImageMap( void )" to remove the following:

// Is there a global pack-start callback?
    if ( Namespace::global()->lookup(StringTable->insert("onImageMapPackStart")) )
    {
        // Yes, so call it.
        Con::executef(2, "onImageMapPackStart", getName() );
    }
...
    // Is there a global pack-end callback?
    if ( Namespace::global()->lookup(StringTable->insert("onImageMapPackEnd")) )
    {
        // Yes, so call it.
        Con::executef(2, "onImageMapPackEnd", getName() );
    }

comment/#if 0 both of those out and you should see a pretty big increase (in one test it gave us about 6 seconds)

#13 we didn't see any decrease at all commenting those out, however we have modified datablock loading to load based on level. We are at 20 seconds on the iPhone (2nd gen) and at about 15 seconds on the 2nd gen iPod touch.

#14 Hmmm, sorry, try the one on line ~465. The other is #ifdef'ed out so it doesn't even compile(change the one after the "#else //normal TGB" line)

#15 I basically ripped out everything unnecessary, including images in the common folder, and got the load time at about 8 seconds flat. The game itself, unzipped, is about 16 MB so I'm fairly happy with the load time.

I think the for next app I try, however, my goal is a flat 5 seconds. One thing that might help, imo, is a simpler button class. One that has maybe just normal and down states. That would cut out 3 images per button.

#16 Do you actually need to specify the other images if you aren't using them? I'm pretty sure I've used buttons with just ONE image fine.

#17 I think you get some warnings when it compiles the .cs files into .dso.... at least in older versions of TGB. But you're probably correct in that the buttons will still work.

It's actually fairly simple in the code to make an explicit 1-image button class. In fact, I did at one to older versions of TGB that allowed you to change their image dynamically as well. I've just yet to add it to the newer TGB codebases.

#18 Dave, I know this is somewhat game specific, but what files did you end up removing? Just giving a quick glance over the source, I feel I can safely remove jpg and gif support and maybe some networking stuff. Did you run into any issues removing the files? We are currently at 25 seconds of loading on the iphone and many times it exits due to taking too long to load. We split out datablock creation to be on a per level basis, so it seems we are running into the same sorts of issues you did.

#19 5 seconds actually is near impossible unless you totally rip the technology appart, removing a major amount of functionality you don't need.

Barebone application launching on the iphone is already ~3 seconds without the iTGB engine code.

but its great to see that the attempts to get the loading time into "acceptable borders" continue and that so many take part, including GG working on that end.

#20 @Geoff

Your profile seems to be major league messed up. You might want to get David to have a look at it for you.