force 16 bit and PNG 16 / RGB4444
by Scott Wilson-Billing · in iTorque 2D · 03/06/2012 (2:34 pm) · 9 replies
Guys,
I'm still trying to reduce memory for my game - getting memory warnings all the time being reported back from our users (via Flurry).
I can reduce memory by forcing 16 bit on a per image basis. This does the trick but many of the images look dreadful.
I've used some cocos2d tool (texture packer) to convert to 16bit PNG and with the right dithering algorithm the result is good. The tool isn't licensed (demo mode) so I haven't tried the resultant image in iTorque2D.
Couple of questions ...
- does Torque natively support RGB4444 textures with the resultant saving in memory (my understanding is a texture can be 16bit or 32bit) ?
- if I have to force 16bit with an RGB4444 texture will I get the same good result I achieved with the texture packer? What I'm trying to say here is will Torque realise this is already 16bit and not try and apply it's own 16bit algorithm for texture reduction.
I'm reluctant to worldwide launch until I've nailed the memory issues.
Thanks
Scott
I'm still trying to reduce memory for my game - getting memory warnings all the time being reported back from our users (via Flurry).
I can reduce memory by forcing 16 bit on a per image basis. This does the trick but many of the images look dreadful.
I've used some cocos2d tool (texture packer) to convert to 16bit PNG and with the right dithering algorithm the result is good. The tool isn't licensed (demo mode) so I haven't tried the resultant image in iTorque2D.
Couple of questions ...
- does Torque natively support RGB4444 textures with the resultant saving in memory (my understanding is a texture can be 16bit or 32bit) ?
- if I have to force 16bit with an RGB4444 texture will I get the same good result I achieved with the texture packer? What I'm trying to say here is will Torque realise this is already 16bit and not try and apply it's own 16bit algorithm for texture reduction.
I'm reluctant to worldwide launch until I've nailed the memory issues.
Thanks
Scott
#2
03/07/2012 (7:42 am)
My tip would be to use pvr images for as much as possible. It really saves a lot of memory.
#3
@Simon, that is a good tip and we do use pvr, however, we have so many images in our game and many are not pow2 so can not be converted to pvr. We could combine into large sprite sheets but then the memory management is much worse as we have gfx loaded which are not necessarily needed for the current level.
03/07/2012 (2:29 pm)
@Johnny, thanks for the feedback. We are getting memory warnings on all devices and judging by the events I see in the log, it seems that the app exits after some of the warnings - the next event I see is a reload of the saved game.@Simon, that is a good tip and we do use pvr, however, we have so many images in our game and many are not pow2 so can not be converted to pvr. We could combine into large sprite sheets but then the memory management is much worse as we have gfx loaded which are not necessarily needed for the current level.
#4
Or you could add extra transparency to the non-pow2 images until they become pow2 and then use source rect to get the sprite to correct size. Then you can use pvr with all images.
03/08/2012 (4:58 am)
Yes the pow2 can really be a bummer with pvr. But if you use large sprite sheets so that you can utilize pvr, wouldn't you still reduce memory usage even with unneccesary gfx loaded for some levels?Or you could add extra transparency to the non-pow2 images until they become pow2 and then use source rect to get the sprite to correct size. Then you can use pvr with all images.
#5
- Torque does support PNG16 / RGB4444 and doesn't mess with the images when you specify force 16 bit.
- I used a tool called texture packer and packed as many static sprites as I could. The author provided me with a beta version of his custom exporter and this allowed me to write a Torque exporter. This honestly saved me days of work.
- I've reduced the memory warnings on the iPad now to very, very occasional and my testers are reporting back that the game is very stable now with just an occasional random crash - which seemed to be caused by the TapJoy library (sigh).
@Simon, I tried PVR and TBH I could never get anything which looked half decent, always the transparent edges became ragged.
03/17/2012 (12:20 pm)
I thought I'd report back on this one.- Torque does support PNG16 / RGB4444 and doesn't mess with the images when you specify force 16 bit.
- I used a tool called texture packer and packed as many static sprites as I could. The author provided me with a beta version of his custom exporter and this allowed me to write a Torque exporter. This honestly saved me days of work.
- I've reduced the memory warnings on the iPad now to very, very occasional and my testers are reporting back that the game is very stable now with just an occasional random crash - which seemed to be caused by the TapJoy library (sigh).
@Simon, I tried PVR and TBH I could never get anything which looked half decent, always the transparent edges became ragged.
#6
TexturePacker with Floyd-Steinberg alpha-dithering does an excellent job.
03/17/2012 (2:25 pm)
PVR has the weakness that it reduces colours in the simplest possible way when scaling down to 4-bit. No dithering whatsoever. You need to manipulate the image in advance for the best possible results, and some images will never look acceptable after colour reduction.TexturePacker with Floyd-Steinberg alpha-dithering does an excellent job.
#7
03/17/2012 (2:45 pm)
@Ronny, yes, I've been using the TexturePacker with Floyd-Steinberg alpha-dithering, very pleased with the results :) 
#8
Thanks.
03/15/2013 (1:03 pm)
On a similar subject, can someone explain to me Torque's "optimize" flag for images? The docs seem fairly vague. It must be a power of two and it can "improve speeds". :)Thanks.
#9
03/15/2013 (1:09 pm)
I'm also seeing a "compressPVR" flag in my datablock. Anyone figure this one out? 
Torque Owner Johnny Vo