Scaling down the no. of bitsÖ

Perhaps an odd query, but any suggestions as to a good technique for scaling down the no. of bits used to hold the RGB components of a pixel of an image? The required no of bits is 5 (range 1 - 0x5); currently the no. of bits is 16 (range 1 - 0x10000); yes, ouch, the term 'lossless' isn't going to be applied here

The 5bit per RGB component limit isn't something I've chosen; I'm trying to code an image converter for the OS X terminal to help with GBA dev, comparable to those available for DOSÖ the images of the output are screenshots taken in Boycott Advance.

Time to break out those bitshift operators, methinks... you'll need to work out 8 pixels at once and put the result into 5 bytes, so that it's all contiguous. Messy but sort-of fun. Must sleep, complain if it's gibberish...

As other people have said, you're going past the true width of the image on each line, which results in that exact slant that you're seeing (I saw the same thing months ago when I wrote my own draw-direct-to-screen function).

Basically you take the number of pixels in a row, and you left shift (<<) it by (imageDepth << 4) (or 0 for 8-bit, 1 for 16-bit, 2 for 32-bit). And to get the proper pixel to start at you take the image's frameBaseAddr + y (in this case 0, since you're doing the whole image) + (x for 8-bit, x+x for 16-bit, x<<2 for 32-bit)

If that makes no sense or it does and it doesn't work, try posting the complete code for the function.

Thanks for the suggestions, but I've found the cause of the problem - the initialisation value of vars in METAL (which I'd used to prep the images for furter conversion) - anyways, I'd been unknowingly preping an unessarry 0xa0 * 0x10 bits worth of pixels, which caused the slant as the unessarry pixels were drawn, 0x10bits worth per line.

The (almost fixed - I need to shift the image a pixel to the right to stop random data deing drawn) looks like thisÖ
Anyways, if anybody wants a copy of the app for some strange reason, just email.