iTGB Crashing on Certain Devices...

#1 Try running the app after a hard restart of the iPhone/Pod. That's why the description of some apps in the app store explicitly require the user to restart the device before app usage. Sometimes, when exiting an app, some data remains in memory, and that could possibly cause issues. It's not just iTGB, but other engines as well.

#2 Thanks for the feedback. I'll add that to my app description, though I'm not sure it will make much difference. The one device that it inconsistently fails on behaves exactly the same after a hard reset. Ugh!

#3 To be honest, even prototypes built with iTGB would sometimes crash back to the home screen randomly, after a remote debug with Xcode. I have two devices that I test my alphas with: an iPhone EDGE, and an iPod Touch 2G. From what I've experienced, the 1st gen iPhone is more problematic than the iTouch 2G. The number of crashes are significantly higher with the old iPhone. Maybe Apple's iPhone OS revisions favor the updated hardware?

#4 the older the device, the slower and the more restricted the platform is.

Worst is 1st generation ipod touch, then old iphone, iphone 3G, then 2nd generation ipod touch.
Thats the order of power and resource availability.

Basically you just have to ensure that your app does not use more RAM than available and that you warn the user if there is not enough RAM left like FieldRunners for example does. A single app with no dynamic quality scaling, that is developed on anything else than the ipod touch first generation, is not really capable of working on the "lower end" devices without extra work.

This naturally means that you will have to get your hands dirty and work with the objc iPhone platform code

#5 So, it sounds like I need to specify "2nd Generation Devices Only" on the app store. I wish I would have known this before publishing!

#6 @Marc: One of the reasons I acquired an iTGB license is so I won't have to touch Objective-C code at all. For the most part, all I've had to work with is pure script, and sometimes behaviors. In some cases, less is more.

@Dan: You would probably lose a lot of sales if you were to put that in your product description .. . I think the best solution would be to scale down your app to accommodate older models to ensure your apps cater to a wider market.

#7 I wish Apple knew, too :)

#8 I can't really scale down the app. It's tiny already. It consists of four small sound files and a handful of Static Sprites. The rest is scripts and behaviors. It's a simple poker game, nothing complex or heavyweight at all.

Some of the other apps done with iTGB don't seem to have this problem. "Enigma Machine" doesn't have a long list of negative reviews complaining that the "app doesn't start" or "won't work". I wonder what I'm doing wrong. When I profile the app it starts fine, doesn't leak memory or do anything obviously stupid. I guess I'll have to buy an older device on e-bay and continue testing. In the meantime, I'm writing my apps in Objective -C.

#9 Oh, it's the poker game you're talking about?? It's the one that people are complaining about??? Wow, I thought it was another project you were referring to .. .

#10 Yep, but I think I've worked it out. I emailed GG support and a very helpful person named Paul convinced me to re-profile the app, and sure enough memory was way high because I accidently had a bunch of unoptimized pngs in the build that I posted to the app store. I'm updating it now. 100% a dumb mistake on my part.

The Bikini Poker application has been selling well despite the nasty reviews due to crashes. I hope that fixing it will help it move up the top 100 list in the casino genre. It's hovering between 26-36 right now. I'm also releasing a free version and two new opponents. I do have a couple more games in the works for release in April. A simple puzzle game and a top-down scroller. I have to say, making games is a lot more fun than managing web developers!

#11 I told you to scale it down. :p
Try pngcrush

#12 Right now the game is running at 51mb real memory and 104mb virtual. The problem I'm having with this is that I don't know what is acceptable on the platform. Every book, website, forum I read says something different about memory usage on the iPhone. I'd like to know where the 104mb is coming from because right now the total disk footprint of all my images and music is 3.3mb. I'm not spawning off large amounts of stuff in the app. Is iTGB just a memory pig? I think I'm going to build a game with no content or scripts and see how big it is.

#13 PNGs are smaller than they will be in graphics RAM.
they will occupy BMP size in VRAM

Also 3.3mb is basically just impossible as the application itself is already larger.
Your asset are only part of the stuff.

the program itself will occupy memory, not selectively loading datablocks will occupy memory, potentially even the art assets connected to them, ...

#14 The pngs were optimized in CS4, most range from a few bytes to 70k. There are 49 images total in the whole app. The deck of cards is actually about 99k but it's a spritesheet containing all the cards and backs. I used PNGOUT on a few files but didn't see much difference so I didn't use it on all the files. Haven't tried pngcrush yet. Audio is 5 files with only one, the theme music, being large at 640k.

Does anyone know which is more efficient in iTGB: one png with 10 sprites or 10 separate png files?

#15 Marc,

3.3 is just the size of my assets on disk. I know that the memory usage is going to be way more, but 50+ ram and 104 virtual seems a bit bloated to me when all I'm loading is 3.3mb worth of stuff. I'm not spawning a zillion sprites or sounds or anything. The scripts and behaviors are pretty simple. I know the game is using the memory, I just don't know why. I need to compile some of the examples and tutorials and see how they compare in terms of resource consumption so I can start to get an idea of what is acceptable.

BTW, thanks to everyone for feedback. Being a noob sucks and your help is deeply appreciated.

Thanks,
Dan

#16 As mentioned, the optimization is of no importance.
so if you have a png with 70k that says nothing about the real size it will have.

png -> BMP size in VRAM

That means:

256x256 would end around 0.25 mb
512x512 would be around 1.0 mb
1024x1024 would end around 4 mb

anything that is not power of two (128,256,512,1024) will be repackaged and take up more memory than before.


if you want smaller sizes, you must use pvr

#17 Interesting. I don't think any of my images are power of 2. I'll look into pvr. Thanks again for the info.

#18 the iphone only supports power of two sizes.
Good thing that TGB generally repackages textures, otherwise your game would just crash basically.
Bad thing is that the repacking also means more vasted texture memory space and possibility to find out what exactly is costing the memory there

#19 I can see that this is clearly one of the problems with this particular app. I'm going to spend the weekend cutting my graphics assets down into powers of 2 chunks. I'm also glad I learned about this before publishing another app!

#20 If you can get PVRs instead of PNGs, they actually take up less memory, too. They are stored in compressed form in graphics RAM. But PVRs *must* be powers of two. The converter won't accept oddly sized input PNGs. Spritesheets made from PVRs would be the most optimal solution.