I use GLKTextureLoader to load a 32bit PNG (created in GIMP). The GLKTextureInfo returned is showing GLKTextureInfoAlphaStateNonPremultiplied for the alphaState on both the simulator and iPad. Experimenting with glBlendFunc and GLKTextureLoader I can get it work on the iPad or simulator, but not both!
With no options to GLKTextureLoader, and with the following blend func:
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
I get on the iOS Simulator (notice the glow on the text is bright)
And on a 4th iPad (notice the glow on the text is dark)
Why the difference? The alphaState is the same. What could it be?
I found the answer on an Apple Discussion.
I have the exact same problem. XCode will convert PNG images so that the header chunk is CgBI (instead of IHDR), and that confuses 3rd party libs like libpng, since a character in Apple's header indicates that the data is in a private format. This operation only takes place for the target device - the simulator is unaffected. There are 4 ways to work around the issue (from easiest to hardest).
1) Rename your images to something else (eg. .ppng), and the XCode packaging tool will ignore your file.
2) According to the following link (http://www.imgtec.com/powervr/insider/sdk/KhronosOpenGLES1xMBX.asp), you need to add the following build settings defintion for each target. IPHONEOPTIMIZEOPTIONS=-skip-PNGs I'm embaressed to say that I still haven't figured out where in XCode project settings to add this.
3) Teach your PNG decoder to handle Apple's CgBI format.
4) Use the Cocoa UIImage classes or the Texture2D.m class.
EDIT: In "Packaging" of "Build Settings" I have found a "Compress PNG Files" option that defaults to "Yes".
Related
I've been trying to make an IOS build on unity but each time I tried I get this message "DXT1 compressed textures are not supported when publishing to iPhone"
I have already change the compression of all my textures to "RGB COMPRESSED PVRTC 4bits" but I still get the same error. based on some answers I found here I have to delete the default checker gray but I have no idea what it is or where I can find it. so if anyone knows please help me...
If you haven't resolved this issue yet then try these solutions.
1- First change all textures from DXT1 to any other compression that is supported for Iphone. Am using RGBA Compressed ASTC.
2- Check all your materials, there will be any material which is using unity built in texture named "Default-Checker-Gray". Just delete this texture from that material and it will resolve your issue. image is also attached below for quick reference.
Default Checker Gray Image
Option 2 resolved my issue and now am able to build xcode project.
Currently, my Assets.xcassets folder is ~13MB with all images for my application. However, when I archive my app the Assets.car that results is closer to 33MB. When using iOSAssetExtractor as described here: What contributes to the size of assets in an IOS App and how can I shrink this? the issue appears to be that the PNGs are blowing up in size when they are "compressed" by Xcode. Many PNGs are 2-3x the size they were before going through the archiving process. This is a common problem that is referenced in multiple places.
The usual solution as referenced here: XCode png compression issue and here: https://imageoptim.com/xcode.html appears to be setting "Compress PNG Files" to No in build settings. This skips Xcode's unpacking and recompression of assets to avoid the asset size bloat that can be experienced. However, this doesn't appear to be working currently and might have stopped working in Xcode 7.3. There is a thread on this in the Apple forums here: https://forums.developer.apple.com/thread/43372 . However, the accepted solution appears to be changing the file type in the inspector to data which works for PNGs in a resources folder but does not appear to be an option for PNGs stored in an xcassets folder.
Note: I've also tried setting "Remove Text Metadata from PNG Files" to no as well with no success.
Can anyone recommend a solution for how to fix this issue in the current (7.3) version of Xcode so that my Assets.car file does not end up 2-3x larger than expected?
The specific problem of PNG sizes getting much larger seems to have been an Apple bug which appears to be addressed now. But, the more general problem of shrinking down each PNG to the smallest possible size is something that can still be solved more effectively. If you are interested in reading about a new delivery codec that can squeeze every last byte out of each PNG, then please have a look at this iOS framework.
I am having my app icon be displayed as a black square instead of the intended image.
I have placed all of my AppIcons into the folder, Im wondering what could be causing this.
Your image needs to be an opaque PNG. No transparency or anything, as well as being the correct size.
If it already is that, try opening it in Preview and re-saving it as a PNG. That way OS X 'generated' it and it should be compatible. If that helps fix the issue, then your image editing program is saving in the wrong format...see info below.
Apple has this to say on generating PNGs:
For all images and icons, the PNG format is recommended. You should avoid using interlaced PNGs.
The standard bit depth for icons and images is 24 bits—that is, 8 bits each for red, green, and blue—plus an 8-bit alpha channel.
I have had this happen when the app is listed as a .png file, but the system is recognizing it as a .jpg or some other type ... find your icon in "finder" and open it with preview, go to the file menu select "export as" and make sure you choose PNG as the save format. Delete the old version in the application, delete the derived data, clean your project, and rebuild the application.
I have the suffixes for iPad and iPad retina screen devices defined as -ipad and -ipadhd for my ccFileUtils for my universal app, and I also have all my graphics included in the correct size for iPad and the retina iPad with the correct suffixes... However whenever I run the app in the simulator it shows the standard without suffix images :/ Like so...
This was a silly error nothing to do with the coding in the end. I checked the file-type of the image in question (Background-iPadhd.png) and it turned out even though it has the extension .png it was in fact a .psd file. It's possible to accidentally save files with a .png extension but in the .psd format if you write the filename as xxx.png but leave the format as .psd when saving from photoshop.
This is related to Default-Portrait.png for iPad: any way to make the file size smaller?
Is there any way to specify a more efficient file format (like JPEG) for Default-Landscape.png
and Default-Portrait.png?
Yes it's possible to use jpg files as launch images. Just add "Launch image" key with the base filename (e.g. LaunchImage.jpg") to the Info.plist. Then add files to your project such as
LaunchImage.jpg
LaunchImage#2x.jpg
LaunchImage-568h#2x.jpg
and Xcode will pick them up.
However through personal experience I've discovered if you're supporting the larger iPhone 5 screen the App Store expects PNG format and uses the presence of PNG to determine iPhone 5 support and display of iPhone 5 size thumbnails on the store. Using JPG images will not show the app as iPhone 5 optimized in the app store (even though it will work fine on the device) so it is best to stick with PNG.
There is no way to use an image other than a png.
All launch images must be PNG files and must reside in the top level of your app’s bundle directory. Section: App Launch (Default) Images
Update: JPEG images to work and Apple's documentation no longer specifies that the images must be PNG files.
If you use xcassets, then since Xcode 6 you can use JPGs. However Xcode will still not let you drop JPGs into the LaunchImage folder. But you can do it in Finder. Simply drop your PNGs into that folder with Finder and then edit the JSON file changing all .png extensions to .jpg.
I haven't submitted an app to the store using this yet, but it works in the iPhone simulator at least.
Update: Doesn’t work on the device. I’ll leave this answer here anyway so people know that this technique was at least tried so the effort won’t be repeated.