TGA or PNG or what???

DigiChainDigiChain Member, PRO Posts: 1,288
I've not been checking in for a while - so TGA support is a new addition since I last looked...

Ok, so which image format should we now be using?

TGA loads much faster - but is also a much, much larger file size.
I'd love faster load times - but my games will be huge! Am I missing something?

What are others doing right now?

Comments

  • vikingviking Member, PRO Posts: 322
    You can use TGA files if you want better performance and you should get the file size back down close to PNG size when you compress your app before submitting it to Apple. However, you will have much larger files during development so testing AdHoc will be slower unless you have really fast upload speed.
  • DigiChainDigiChain Member, PRO Posts: 1,288
    Cheers Viking,
    So have you tested / experienced this reduction in file size when submitting to Apple?
    What about when submitting to Google, Amazon etc?

    Is there any official GS statement on best practices for this?
  • CodeWizardCodeWizard Inactive, Chef Emeritus Posts: 1,143
    edited July 2013
    TGA is larger on disk. Until compressed. Then it's comparable to PNG. This is because PNG is based on zlib / zip compression -- just like APKs on Android and apps on iOS. So taking your TGA images and zipping them up gives you a decent comparison.

    Here's a test comparison with a local TGA on my machine:

    World2.tga size is 1,048,620
    World2.png size is 62,039
    World2.zip size is 68,256

    So, they're really close.

  • DigiChainDigiChain Member, PRO Posts: 1,288
    Ok, thanks @CodeWizard.

    So in other words - yes use TGAs!

    Cheers
  • JSprojectJSproject Member Posts: 730
    edited July 2013
    TGA is larger on disk. Until compressed. Then it's comparable to PNG. This is because PNG is based on zlib / zip compression -- just like APKs on Android and apps on iOS. So taking your TGA images and zipping them up gives you a decent comparison.

    Here's a test comparison with a local TGA on my machine:

    World2.tga size is 1,048,620
    World2.png size is 62,039
    World2.zip size is 68,256

    So, they're really close.

    I think it's great that you have introduced the possibility of using TGA-files but in my tests the file size difference (between png and zipped tga) is quite dramatic and definitely not "really close".
    Maybe you used an uncompressed png file in your example (I compress all png files I use).

    Some examples below.

    Test1:
    png (87 KB) - 32 bit file with alpha channel/transparency (compressed file)
    tga (652 KB) - 32 bit file with alpha channel/transparency (uncompressed file)
    tga.zip (146 KB) - compressed using 7zip (using standard zip format) with compression level "ultra"


    Test2:
    png (303 KB) - 32 bit file with alpha channel/transparency (compressed file)
    tga (652 KB) - 32 bit file with alpha channel/transparency (uncompressed file)
    tga.zip (403 KB) - compressed using 7zip (using standard zip format) with compression level "ultra"


    Test3:
    png (3043 KB) - 24 bit file, no alpha channel (compressed file)
    tga (9217 KB) - 24 bit file, no alpha channel (uncompressed file)
    tga.zip (5492 KB) - compressed using 7zip (using standard zip format) with compression level "ultra"
  • natzuurnatzuur Member Posts: 304
    TGA is larger on disk. Until compressed. Then it's comparable to PNG. This is because PNG is based on zlib / zip compression -- just like APKs on Android and apps on iOS. So taking your TGA images and zipping them up gives you a decent comparison.

    Here's a test comparison with a local TGA on my machine:

    World2.tga size is 1,048,620
    World2.png size is 62,039
    World2.zip size is 68,256

    So, they're really close.

    I think it's great that you have introduced the possibility of using TGA-files but in my tests the file size difference is quite dramatic and definitely not "really close".
    Maybe you used uncompressed png files in your example (I compress all png files I use).

    Some examples below.

    Test1:
    png (87 KB) - 32 bit file with alpha channel/transparency (compressed file)
    tga (652 KB) - 32 bit file with alpha channel/transparency (uncompressed file)
    tga.zip (146 KB) - compressed using 7zip (using standard zip format) with compression level "ultra"


    Test2:
    png (303 KB) - 32 bit file with alpha channel/transparency (compressed file)
    tga (652 KB) - 32 bit file with alpha channel/transparency (uncompressed file)
    tga.zip (403 KB) - compressed using 7zip (using standard zip format) with compression level "ultra"


    Test3:
    png (3043 KB) - 24 bit file, no alpha channel (compressed file)
    tga (9217 KB) - 24 bit file, no alpha channe (uncompressed file)
    tga.zip (5492 KB) - compressed using 7zip (using standard zip format) with compression level "ultra"
    Correct me if im wrong, but aren't compressed pngs going to be uncompressed by iOS (and GS?) anyway, so your not saving the compressed file space in the long run? If that's the case, CodeWizards numbers are probably accurate.
  • JSprojectJSproject Member Posts: 730
    edited July 2013
    @natzuur, If compressed png files are imported using the creator then yes they will be uncompressed. If you go to your project folder, show package content and then replace the images with your compressed png-files those will be used instead. Also, I may add that I'm only talking about file size here (not memory impact).
  • natzuurnatzuur Member Posts: 304
    But when publishing a game will this hold? Or is it going to go through a step that will address the images and flag for re-compression because of the way Xcode Defaults the setting for compression, and since the reason for the re-compression is to improve and standardize the drawing performance, is it worth it in the case it doesn't re-compress?
  • JSprojectJSproject Member Posts: 730
    But when publishing a game will this hold? Or is it going to go through a step that will address the images and flag for re-compression because of the way Xcode Defaults the setting for compression, and since the reason for the re-compression is to improve and standardize the drawing performance, is it worth it in the case it doesn't re-compress?
    Those questions are very good and I've been thinking of those myself before :). I do believe that xcodes default png compression is turned of by GS during the publishing process (thus allowing us to use our own compressed files). Would be great if @CodeWizard (or some other GS official) could confirm.

    On the other hand, if the xcode compression IS actually used (thus nullifying our own compressed files) then that would render @FryingBaconStudios guide on image optimization (and all the forum threads about it prior to his video) useless/pointless.

    In regards to your last question I'm quoting imageoptim.com/xcode
    "xcode's built-in (de)optimization
    Xcode for iOS by default converts all PNG images to a non-standard iOS-specific PNG derivative. This format saves iOS devices a trivial conversion step during loading, because it uses premultiplied BGRA instead of RGBA color space. It doesn't affect rendering speed at all."
  • DigiChainDigiChain Member, PRO Posts: 1,288
    Yeah, I have to admit I'm still not completely sold on the TGA file size comparison either.
    I've always optimized my PNGs which have given huge file size savings, and in turn this has kept my delivery package sizes at reasonable/low sizes.

    I've just rendered out a few images for a new project - now working at the 'new' 2048x1536 ipad size and the TGA file sizes are pretty damn large!
  • The_Gamesalad_GuruThe_Gamesalad_Guru Member Posts: 9,922
    Yes the 50mb limit for cell phone delivery of an App is hard to stay under for most games. Every bit counts. I'm not sold on TGA for iPhone apps. IPad yes.
Sign In or Register to comment.