I'm sorry for the stupid question but I need a "practical" answer, reading the redbook v1.1 it looks like drawing 2D images is quite complicated...

So from what I understand I need a PNG loader, an array to keep the image pixels data (stored in RGBA possibly), and then I paste these images with glDrawPixels(width, height, GL_RGBA, GL_BYTE, const GLvoid *pixels) or something.

Are there standard higher level functions to make life easier? Libraries everone uses?

I'll never manage to do it "right" if I try on my own... need code

You could always load the image using an NSImage, then get the NSBitmapImageRep, and you can then get the actual data of the image using the bitmapData from NSBitmapImageRep. This is what you can pass into glDrawPixels (or create a texture out of it and draw it to a quad)

NEVER try to access the pixels of an NSBitmapImageRep you didn't create explicitly by hand yourself. This is a recipe for PAIN, as many people discovered in the 10.3->10.4 transition.

If you need cross-platform code, libPNG is your best bet. This code shows how to get load a PNG file from disk:
http://onesadcookie.com/svn/repos/RubyGa...urce/png.c
After that, you put the image into a texture and draw it on a quad.

If you just care about Mac OS X, QuickTime (10.3 and below)
http://onesadcookie.com/svn/repos/QTValuePak

or ImageIO (10.4 and above)
http://gamewiki.evolpenguin.com/index.ph...re_Loading

Quote:If you need cross-platform code, libPNG is your best bet. This code shows how to get load a PNG file from disk:
http://onesadcookie.com/svn/repos/Ru...n/Source/png.c

nice, thx

Quote:After that, you put the image into a texture and draw it on a quad

Aaah... cool.

Thanks

Question for OSC:

What do you think of pre-processing PNG textures into a flat file format (i.e. width, height, followed by raw RGBA data) and then just zLib'ing the mess to save some disk space. Then you could use whatever (even NSBitmapImageRep) in your preprocessing tool, but your released game wouldn't rely on anything external so OS API changes wouldn't bite you later.

I'd also have to imagine this would load textures faster as you wouldn't have all the PNG processing for all the possible variations that could be in a PNG that never appear in our simple textures.

I know we did something similar by in my day in the biz, but for entirely different reasons (i.e. GameBoy unsurprisingy doesn't have a built in PNG decompress routine )

Do you do anything similar in your titles OSC?

Seriously, I wouldn't bother. Just use libpng or libjpeg and forget about it.

It might well be worthwhile compressing to DDS files offline with a high-quality DXT compressor and reading the DDS files in "manually", but I'd still pick DDS rather than inventing a random new file format.

zKing Wrote:What do you think of pre-processing PNG textures into a flat file format (i.e. width, height, followed by raw RGBA data) and then just zLib'ing the mess to save some disk space. Then you could use whatever (even NSBitmapImageRep) in your preprocessing tool, but your released game wouldn't rely on anything external so OS API changes wouldn't bite you later.

It's called TGA

(I blame NeHe )

What about glPNG, so simple that all you have to do is pass a file path and get back a gl texture. If you like, there is more functionality, although I have looked at the code and it handles everything very well. For what you are doing you can just call glPngRaw and get back the raw data in RGBA or many other formats. I have used it ever since I found it.

http://www.wyatt100.freeserve.co.uk/download.htm

If you want the static libraries that I have compiled just e-mail me.