iTGB Crashing on Certain Devices...

#21 What sucks is the latest version of the PVR compression tool from Imagination Technologies is only for Windows and Linux, so good thing I have Boot Camp and Parallels. You can find it HERE.

I believe the iPhone SDK comes with a Mac version of PVRTexTool.

/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/texturetool

pngcrush can also be found in this directory.

Additionally, appending the parameter -l to texturetool yields:

./texturetool -l

Encoders:

PVRTC
 --channel-weighting-linear
 --channel-weighting-perceptual
 --bits-per-pixel-2
 --bits-per-pixel-4

Formats:

Raw
PVR

And -h yields:

Usage: texturetool [-hlm] [-e <encoder>] [-p <preview_file>] -o <output> [-f <format>] input_image

	-h			Display this help menu.
	-l			List available encoders, individual encoder options, and file formats.
	-m			Generate a complete mipmap chain from the input image.
	-e <encoder>		Encode texture levels with <encoder>.
	-p <preview_file>	Output a PNG preview of the encoded output to <preview_file>. Requires -e option.
	-o <output>		Write processed image to <output>.
	-f <format>		Set file <format> for <output> image.

EDIT:

Additional Resource -- Apple's PVRTextureLoader sample Xcode project.


@ Dan: You could replace the included brick wall graphic with your own assets to see how the different compression settings affect image quality on the actual display

#22 One of my customers found that my game was crashing his iPhone 3G. After deleting and reinstalling, re-syncing his iPhone and other attempts to fix it he finally discovered that if he deleted other development apps (he was also using that iPhone for development) my game stopped crashing.

#23 @ Marc:

Either I'm confused, or you're confused about the power of 2.

As specified in Apple's iPhone Reference Library, the requirements for utilizing PVRTC on the iPhone are as follows:

- Texture MUST be square
- Texture MUST be power-of-two in length

These two requirements are not either/or, it HAS to be both.
Now, looking at your post:

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

I'm a bit confused because 128, 256, 512, and 1024 ARE power-of-two in length.

---

As a side note, suppose you have two textures:
Texture #1 is 128x256
Texture #2 is 640x640

Texture #1, although length and width are power-of-two, can't be converted to PVR format because it's not a square texture.

Texture #2 although a square texture, also cannot be converted to PVR format because 640 is not power of two (128+512=640).

If I'm wrong someone please correct me.

#24 PNGs are corrected by TGB to the right, square sizes. PVRs must be square right from the start. Somebody please fix the iTGB loader so we can use Apple's tool :)

#25 I am having this problem too, but a *careful* look at the console log showed why it doesnt run on Iphone. Mine also quits after default finishes showing. It runs fine on iPods.

While texture optimization certainly can't hurt, and I hope it solves the problem for you, my problem is that the game actually takes TOO LONG TO INITIALIZE!!!!!!! It gets to the main menu and exits out. Something called Springboard on the iPhone is saying the game took too long to initialize, assumes it's crashed, and exits out. The vast majority of that launch time is the engine launching, so there's not too much I can do, except to move my datablock loading. This will give 2 large loading times instead of one.

#26 Good advice! That explains many problems - the most recent revision of iPod touch can be more than twice as fast at simply launching a program compared to the most recent iPhone revision.

#27 This is a good discussion. I've managed to reduce Bikini Poker by about 50% simply by slicing my pngs up more efficiently. I'm not using pvrs or any compression. I ran instruments against a version with compressed pings vs. non-compressed pings and the memory usage was the same. So the only way for me to keep image quality and have a decent memory footprint is to reduce the dimensional size of most of the images. This is working well and I'm at about 19 mb total for the free version (one opponent) and 28 mb (for the full version with five opponents). Virtual memory is hanging right around 70mb for both versions. BTW, iTGB takes about 11mb real and 64mb virtual before you even add assets or game logic. So I figure if an app is between 20-30 mb you're doing ok, but I have no guidelines or metrics to base this assumption on.

If your app is taking too long to load, try reducing the total bytes size of your assets. Even though image compression had no affect on memory usage, it did greatly improve load time. Version 1.0 of Bikini Poker takes 16-18 seconds to load, the next update will take about 8-10 seconds.

I hope GG has fixed image/resource handling in 1.2 - which is ready and will be in our hands soon from what I've heard through the grapevine.

Thanks to the iTGB forums community for such great info and support!
Dan

#28 Apple won't approve apps that take more than 30 seconds to load, so guys be careful.

#29 Reducing the *number* of files to load also reduces load time, just like with harddrives.

#30 Ronny: I am sorry, don't understand what you mean.
Never mentioned that you can skip either to do pvr compression.

We were talking about texutres in iTGB.
iTGB bases on TGB and TGB repackages textures to meet requirements.
It will not use your textures 1:1 unless they completely fullfill the requirements.

#31 What I mean is that opening more files takes longer than just opening one file. The fewer files are opened, the more efficiently loading should work.

#32 Sorry should have pointed out that I am answering to far aboves posting.

That more files mean more loading time is logical.
Most optimal is actually if you create "per level datablock files" and only exec the current levels datablocks when loading
This will make a pretty large difference.

PVRs will further reduce the loading time as they remain compressed in memory, while PNG / JPG have to be decompressed to pure bmp data and use a correspond amount of RAM.
They can naturally not be avoided for UI but otherwise, also consider the requirement for uncompressed image data carefully, because each pvr means reduction of RAM usage (and loading time therefor) to 1/4 to 1/8th when compared to the corresponding non pvr texture

#33 Some of our users are also experiencing crashes on start up, on first screen. They say that the game works after restarting the game two, three or four times (who knows?!?), and restarting the device. The crashes happen in our two released games, and mainly on OS 3.0. We are wondering if there is any kind of compatibility issues between iTGB 1.2 and iPhone OS 3.0. The curious fact is that such crashes do not occur during development, which makes it virtually impossible to solve it!

Has anybody already experienced those crashes?


Thanks.

#34 It's likely memory related. OS 3.0 makes even less memory available to your application because of the addition of the new spotlight process. Restarting the device is the best way, but sometimes your application using all of the memory on the system also causes other processes to be jetisoned freeing up more memory for the next run attempt. In all likelyhood you will either need to reduce your applications memory consumption or document with your application that they should reboot the device before running your application.

#35 Crash stopping after restarting: Thats a common problem with the iphone OS not releasing the memory correctly or not shutting down background stuff right.
For example after larger installs you will commonly not be able to avoid restarts as the amount of memory left does not even suffice to run a larger webbrowser session.

#36 Do like more and more people are doing: First thing in your WHAT'S NEW description should be a reminder to reboot the device. It's the "nuke from orbit" option on iPhone OS :/