Questions about moving art from TGB (T2D) to ITorque 2D
by Blake Drolson · in iTorque 2D · 10/02/2012 (7:44 pm) · 11 replies
Hi there,
So we are about to start the work of porting our game Drip Drip, over to iTorque 2D to run on the iPad. We have a number of art preparation questions...
1) For creating texture sheets with multiple textures on it, what is the maximum size of the texture, to keep at power of two sizes, and still be manipulated in a speedy fashion. 2048 x 2048 , 4096 x 4096, non-square ?
2) Our building's are built from 256x256 tiles, together in a tilemap. Should we put the building tiles together on one texture sheet?
3) If we use the force16bit flag, does that mean all images on a texture sheet share one 16 bit pallet, or does each image on the texture sheet get its own 16 bit pallet?
4) If you force an image to 16bit pallet, what happens to the alpha channel if we have areas of alpha values in a smooth falloff? Is there a way to get more than 1 bit of alpha when forcing 16 bit?
5) Is it benificial to have images saved in a format using 16 bits if they will be forced to 16bit anyway? What is the best tool to reduce to 16 bit formats, and whats the best format to save in?
Thank you for any information related to our questions!
So we are about to start the work of porting our game Drip Drip, over to iTorque 2D to run on the iPad. We have a number of art preparation questions...
1) For creating texture sheets with multiple textures on it, what is the maximum size of the texture, to keep at power of two sizes, and still be manipulated in a speedy fashion. 2048 x 2048 , 4096 x 4096, non-square ?
2) Our building's are built from 256x256 tiles, together in a tilemap. Should we put the building tiles together on one texture sheet?
3) If we use the force16bit flag, does that mean all images on a texture sheet share one 16 bit pallet, or does each image on the texture sheet get its own 16 bit pallet?
4) If you force an image to 16bit pallet, what happens to the alpha channel if we have areas of alpha values in a smooth falloff? Is there a way to get more than 1 bit of alpha when forcing 16 bit?
5) Is it benificial to have images saved in a format using 16 bits if they will be forced to 16bit anyway? What is the best tool to reduce to 16 bit formats, and whats the best format to save in?
Thank you for any information related to our questions!
#2
10/03/2012 (1:24 pm)
UnChaos is shit. Use TexturePacker! It also lets you colour-reduce in advance with dithering, so that RGB565/4444 images look better when converted to PVR. The official PVR tools don't do any decent dithering at all.
#3
10/03/2012 (7:05 pm)
Thanks for the feedback guys, we will look into it soon so its appreciated. So I guess we should forget any kind of smooth alpha channel falloffs if we reduce to 16 bit?
#4
10/03/2012 (10:13 pm)
It depends. TexturePacker has two algorithms with alpha-channel variants. RGBA4444 can look identical. Give it a try. The 3.x versions can export PVR directly now. 
#5
Thanks for the info on the TexturePacker, it looks good.
www.codeandweb.com/texturepacker $20
>What data format (cocos2d, etc) do you use to create.
>Do you have a link for how the dithering options work.
10/04/2012 (7:39 am)
@RonnyThanks for the info on the TexturePacker, it looks good.
www.codeandweb.com/texturepacker $20
>What data format (cocos2d, etc) do you use to create.
>Do you have a link for how the dithering options work.
#6
10/04/2012 (5:19 pm)
Thanks so much for the tips on TexturePacker, looks like we will use it, nice they output PVR directly too. Also good to know that there is a RGBA4444 format for 16bit, all very good info ! :) 
#7
10/04/2012 (7:58 pm)
Retina display devices (new iPad and iPhone 4S) have maximum texture sheets of 4096. 
#8
Lemme throw out a few myths and practices and see what I can get right.
PVRTC can compress in a way that can actually load compressed into system RAM for rendering, but no other format does that?
I've used TexturePacker to make sprite sheets and I often told it to make PNGs of RGBA5555 since that seemed to look the same but be smaller. However, the final PNGs, when checked in Windows and Gimp and other apps claim to be "32 bit". So I guess I didn't save anything here but I clamps back my integrity a tad for nothing.
The next step is apparently to use Mac PVRTC? I'm surprised that it's a good idea to compress the images AFTER THEY ARE IN the sprite sheet. Seems that would cause some edge bleeding or something.
I'm assuming that I can take my texture sheets now, which are probably 32 bit (but created as if RGBA5555) and run PVRTC. Then the results should be useful directly in Mac as compressed a lot albeit kinda lossy and not great?
Thanks!
03/15/2013 (12:30 pm)
@Dean, I'm losing you on the creating of two sheets, one 16 bit and one full color?Lemme throw out a few myths and practices and see what I can get right.
PVRTC can compress in a way that can actually load compressed into system RAM for rendering, but no other format does that?
I've used TexturePacker to make sprite sheets and I often told it to make PNGs of RGBA5555 since that seemed to look the same but be smaller. However, the final PNGs, when checked in Windows and Gimp and other apps claim to be "32 bit". So I guess I didn't save anything here but I clamps back my integrity a tad for nothing.
The next step is apparently to use Mac PVRTC? I'm surprised that it's a good idea to compress the images AFTER THEY ARE IN the sprite sheet. Seems that would cause some edge bleeding or something.
I'm assuming that I can take my texture sheets now, which are probably 32 bit (but created as if RGBA5555) and run PVRTC. Then the results should be useful directly in Mac as compressed a lot albeit kinda lossy and not great?
Thanks!
#9
03/15/2013 (12:42 pm)
Update: I just tried TexturePacker with RGB4444. The final disk image is smaller, but Windows and Gimp both call it 32 bits or "RGB". Hmm. Seems like TP may not be saving some useful data that would keep iPad from puffing up the RGBs?
#10
Charlie if you having issues working this out, and post any questions , I can ask Thomas to come here and answer them for you.
03/16/2013 (2:20 pm)
We have been using texture packer with a lot of sprite sheet at 2048 x 2048, compressed to RGB4444. The come out at 2MB, which is a great savings, and load really fast with the GLKit extensions (we using iT2d 1.50 community edition from Paul Jan). Thomas my partner and artist on Drip Drip is not entirely happy with some of the compression artifacts, so we are likly dropping ipad 1 support in order to get a bigger memory budget (ipad 1: ~100mb, ipad 2: ~200mb) and use RGB8888 for some sheets, but they go from 2mb to 16mb when you do that.. Charlie if you having issues working this out, and post any questions , I can ask Thomas to come here and answer them for you.
#11
I did figure out that if I load them into Torque using the force16bit flag, that my game lasts longer on iPhone before crashing. :) So I think that setting does use them as RGBA4444. It probably would have done this even if they were RGBA8888 so I don't know if I got anything from TexturePacker.
The next step was that I used the Mac's "texturetool" to create "PVR4a" files. It appears that Torque gets confused on these. After waiting over a minute, I paused the debugger and saw that Torque was working in a loop assuming a PVR4a file of several million lines in height! Still haven't figure that one out.
I'll keep you updated. It's too bad to hear about skipping the iPad1. Apple claims that your program should be backwards compatible with iPad1 to get into the App Store, but maybe not if you use an iOS version that is newer than the iPad1 can handle.
03/16/2013 (9:02 pm)
Thanks. I've done a little more research and experimentation. I still can't see if my RGBA5555 and RGBA4444 images are marked as having less bits. All tools tell me the are 8-bit color in them. They are smaller on disk but that does not prove anything because if they have had their colors limited, that could lead to better PNG compression.I did figure out that if I load them into Torque using the force16bit flag, that my game lasts longer on iPhone before crashing. :) So I think that setting does use them as RGBA4444. It probably would have done this even if they were RGBA8888 so I don't know if I got anything from TexturePacker.
The next step was that I used the Mac's "texturetool" to create "PVR4a" files. It appears that Torque gets confused on these. After waiting over a minute, I paused the debugger and saw that Torque was working in a loop assuming a PVR4a file of several million lines in height! Still haven't figure that one out.
I'll keep you updated. It's too bad to hear about skipping the iPad1. Apple claims that your program should be backwards compatible with iPad1 to get into the App Store, but maybe not if you use an iOS version that is newer than the iPad1 can handle.
Torque 3D Owner Dean Parker
Serendip Games
>The limits for texture sheets...
iPad 2048
iPhone 4 2048
iPhone 3GS 2048
iPhone 3G 1024
iPhone 1024
iPod touch 3nd Gen 2048
iPod touch 2nd Gen 1024
iPod touch 1st Gen 1024
>iTorque comes with a great utility UnChaos (Windows) that will take all your 256x256 and it will create a texture sheet for you.
>Once you have created your texture sheet, the utility (PVRTC) will compact the images and they will greatly increase the load time and performance.
>All textures on the sheet will get the 16 bit flag. You could create separate sheets - 16 bit and true color.
I find the best way to do things, the source images (before changes), should be saved in .png, the UnChaos will convert your image to .png and the PVRTC will convert the image to .pvr
I found when using PVRTC the image is incredibly small and you do not really need a 16 bit version. I also found the 16 bit versions, does not look great and PVRTC compression tends to make it look worse.
If you want 16 bit image, the best way is to have a source in true color and a working version in 16 bit. That way, if you need to do changes, you have the original true color version.
Do Testing
The best way, is to create a true color texture sheet, convert to .pvr, then compare that to 16 bit .png converted to .pvr.
In other words, you will be comparing your game with 16 bit images vs true color images. I was not happy with the 16 bit version, but you may like the results.