Loading in PNG's (and other) bitmaps.

Member
Posts: 129
Joined: 2009.03
Post: #1
Hello,

I'm pretty new to iPhone dev (but quite looking forward to getting stuck in), I'm a bit unsure what the best practice is, and options are, in regards to loading in bitmap textures in to video ram for use with OpenGL.

I've come across PVRTC compression (using 'texturetool'), but I believe that's not going to retain an alpha channel.

Some of my sprites will make use of Alpha channel, and if I was on PC or Mac, they'd be 32bit PNG's etc. From what (limited) knowledge I have currently, I imagine the PVRTC textures, and compressed in to a format ready to go straight in to VRAM; while regular PNG's will require unpacking in to normal iPhone RAM, before uploading to VRAM (taking up 32bpp, compared to the 2 or 4bpp of the PVRTCs).

There's good chance I'm missing something here! Are there any good tutorials, or sources of information etc; detailing the various ways, and relative merits, of getting bitmap files in to VRAM on iPhone.

Hope someone can shed a little light, many thanks,
Jamie. Smile
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #2
You can search around the forums here for plenty of examples of how to load textures on iPhone.

AFAICT, I think most of us pretty much just use regular ol' 32 bit PNGs for images on iPhone for most purposes. If you're using a lot of RAM then you can drop down to PVRTC, which does also have alpha, but it kinda sucks on the edges. I tend to use PVRTC for backgrounds and animated sprite frames, but everything else PNG. Non-alpha images work great with PVRTC though. Yes, PVRTC is just a blob of pixels that you upload directly from disk to the GL without any processing/unpacking. PNGs you will probably just use some OS routines if you don't care about premultiplied alpha, otherwise you can use libpng or a small variant of SOIL (sorry I don't have the name or link handy, but search the forums for SOIL on iPhone and you're bound to find it).
Quote this message in a reply
Member
Posts: 129
Joined: 2009.03
Post: #3
Ah, thanks Jake, that's really useful, and clears things up a lot! Smile

I imagine you use PVRTC for animating sprites, as the player won't get to pay so much attention to each individual frame of animation etc; and can also imagine them being good for backgrounds, and solid background tiles etc.

I really don't want my sprites with pre-multiplied alpha (all the semi transparent pixels must look wrong?), so I guess that means no OS routines for loading in and unpacking PNG's in to RAM..

Someone was suggesting: "load them as an image (UIImage or CGImage), create a bitmap context, draw them into the bitmap, then use an opengl call to make a texture out of that bitmap" ... and I've been looking at some code which seems to do that, but I think it uses OS routines (CGImageCreateWithPNGDataProvider and other CGImage* stuff).

I'm guessing a combination of the PVRTCs (esp, if my game wants to put a lot in to VRAM), and 32 bit PNG's, that I need to use libPNG or SOIL to unpack etc; will work best for me.

Thanks once again,
Jamie. Smile

EDIT: I assume, if a game isn't cramming so much in to VRAM, then there's not so much need to use PVRTCs, as you get pretty good compression with normal PNG files (so it wouldn't be an issue in terms of your games' install file bundle thingy)?
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #4
Jamie W Wrote:I imagine you use PVRTC for animating sprites, as the player won't get to pay so much attention to each individual frame of animation etc; and can also imagine them being good for backgrounds, and solid background tiles etc.
Exactly. Sometimes there might be stationary frames of a sprite animation, and for that one frame I'll use a PNG for best looks, but yeah, the ones that are busy animating, you can't see the PVRTC artifacts at all, so if you have lots of frames it can save a boatload of RAM.

Jamie W Wrote:I really don't want my sprites with pre-multiplied alpha (all the semi transparent pixels must look wrong?)
Actually, it's not a problem at all for me. Just use GL_ONE, GL_ONE_MINUS_SRC_ALPHA for the blend mode and it looks just like it would otherwise. The only time you might not want premultiplied alpha is if you're using the loaded image for a shader or some special software rendered effect, which isn't generally going to be feasible on the current crop of iPhones. You could use shaders on the 3GS, and presumably iPad, but even then, do you actually need non-premultiplied alpha? So unless you actually have a special need for it, premultiplied is just fine. You'll have to change your color submission though, so that's it's like glColor4f(r * alpha, g * alpha, b * alpha, alpha);, which might be a minor annoyance. It's all your call though. The OS routines are easiest to use though IMHO.

Jamie W Wrote:Someone was suggesting: "load them as an image (UIImage or CGImage), create a bitmap context, draw them into the bitmap, then use an opengl call to make a texture out of that bitmap" ... and I've been looking at some code which seems to do that, but I think it uses OS routines (CGImageCreateWithPNGDataProvider and other CGImage* stuff).
Yep, that's the stuff you're looking for Wink The CGImageCreateWithPNGDataProvider stuff is what I use, as it is the same code to load on the Mac.

Jamie W Wrote:I'm guessing a combination of the PVRTCs (esp, if my game wants to put a lot in to VRAM), and 32 bit PNG's, that I need to use libPNG or SOIL to unpack etc; will work best for me.
Yes, that's probably going to be ideal if you don't want premultiplied alpha for your PNGs. I don't think SOIL works on iPhone though, so like I mentioned, you'll have to use a stripped down version of it (again, forgot the name of the stripped down version).

Jamie W Wrote:EDIT: I assume, if a game isn't cramming so much in to VRAM, then there's not so much need to use PVRTCs, as you get pretty good compression with normal PNG files (so it wouldn't be an issue in terms of your games' install file bundle thingy)?
Exactly! Yes, the compression on disk is better with PNG, but in RAM, nothing beats PVRTC, so it's a trade-off to be considered.

Sounds like you're right on track. Smile
Quote this message in a reply
Member
Posts: 129
Joined: 2009.03
Post: #5
Ah cool, things are getting a lot clearer thanks!

I'm using a custom tool (which runs as a command line app, not sure what you'd call those in OSX) to generate texture atlases, and I'd like to call texturetool from within this app, to generate PVRTC textures etc.

So something like running a string, as if it's been typed in terminal, but from within an app. Is that kind of thing possible?

Thanks,
Quote this message in a reply
Member
Posts: 249
Joined: 2008.10
Post: #6
BTW, PVR is just a container, as DDS, actually you can store textures inside PVR files without compresion of any type, as BMP.

My program only uses PVR textures, but some of them are compressed (specially those ones wo alpha) and for animations I compress them. Actually I realised compressed PVR only have a bad quality when there is an alpha channel, but not in other case, especially when developing a 2D game.

I recommend you download a tool from http://www.imgtec.com/ called PVRTexToolGUI.

Hope this helps.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #7
Jamie W Wrote:Ah cool, things are getting a lot clearer thanks!

I'm using a custom tool (which runs as a command line app, not sure what you'd call those in OSX) to generate texture atlases, and I'd like to call texturetool from within this app, to generate PVRTC textures etc.

So something like running a string, as if it's been typed in terminal, but from within an app. Is that kind of thing possible?

Thanks,

I've used NSTask and NSPipe to do that, but it's not as easy to do as I wish. You can try checking out the Moriarty sample at Apple.
Quote this message in a reply
Post Reply