AnotherJake Wrote:Looks like fun, I wanna play too! How about:

Code:

#define BYTES_PER_PIXEL    4
memset(textureData, 0, texWidth * texHeight * BYTES_PER_PIXEL);

or maybe better yet:

Code:

#define FOUR_BYTES_PER_PIXEL    4
memset(textureData, 0, texWidth * texHeight * FOUR_BYTES_PER_PIXEL);

You'd clearly want to make that an enum instead of a define.

Bachus Wrote:You'd clearly want to make that an enum instead of a define.

That'd be my choice as well, so you get type checking, but yours wouldn't work either. Have to do it this way instead:

Might as well define some more while you're at it:

backslash Wrote:No you're not - RGBA with unsigned bytes is 4 separate single bytes, which happens to be the same size as an unsigned int on many systems, but you are making the very mistake you are telling us all to avoid. I like Jake's solution.

On the other hand 565 RGB is what ? 5 bites of red , 6 bits of green and 5 bits or blue ? ... or more is more likely to be referred as unsigned short ?

warmi Wrote:On the other hand 565 RGB is what ? 5 bites of red , 6 bits of green and 5 bits or blue ? ... or more is more likely to be referred as unsigned short ?

AnotherJake Wrote:That'd be my choice as well, so you get type checking, but yours wouldn't work either. Have to do it this way instead:

Curses. Hoisted by my own petard.

ha ha ha ha ha ha

AnotherJake Wrote:

Code:

enum {
    RGB_565_BYTES_PER_PIXEL = 2
};

Perhaps , but once you end up writing code trying to manipulate individual bits ( as you would if you were to attempt to update the buffer) you would end up casting it back and forth into unsigned short or unsigned int depending on how optimized you want your code to be and RGB_565_BYTES_PER_PIXEL would be of no use at all.

warmi Wrote:Perhaps , but once you end up writing code trying to manipulate individual bits ( as you would if you were to attempt to update the buffer) you would end up casting it back and forth into unsigned short or unsigned int depending on how optimized you want your code to be and RGB_565_BYTES_PER_PIXEL would be of no use at all.

unsigned short *pixels = (unsigned short *)malloc(texWidth * texHeight * RGB_565_BYTES_PER_PIXEL);

No cast needed past the malloc (or calloc or whatever), and this is standard practice anyway.

Whatever, dude, it wouldn't matter to me either way. All I've ever said was that sizeof(unsigned int) isn't any more less-magic-number-ish than... 4.

AnotherJake Wrote:unsigned short *pixels = (unsigned short *)malloc(texWidth * texHeight * RGB_565_BYTES_PER_PIXEL);

No cast needed past the malloc (or calloc or whatever), and this is standard practice anyway.

Whatever, dude, it wouldn't matter to me either way. All I've ever said was that sizeof(unsigned int) isn't any more less-magic-number-ish than... 4.

hehe .. yeah, but then again if you are going to do this:

you are explicitly indicating you will be operating on the buffer in terms of unsigned shorts so I see absolutely nothing wrong with using:

In fact , the first thing a programmer will think when looking at your code is something like ... hmm, what is RGB_565_BYTES_PER_PIXEL ... it must be unsigned short since he is casting to it.

warmi Wrote:you are explicitly indicating you will be operating on the buffer in terms of unsigned shorts so I see absolutely nothing wrong with using:

Code:

unsigned short *pixels = (unsigned short *)malloc(texWidth * texHeight * sizeof(unsigned short));

... uh, because there *isn't* anything wrong with using that. You were the one that complained about using magic numbers All I've (we've) been saying is that it isn't any better than
in terms of magic-number-less-ness.

warmi Wrote:In fact , the first thing a programmer will think when looking at your code is something like ... hmm, what is RGB_565_BYTES_PER_PIXEL ... it must be unsigned short since he is casting to it.

That is not at all what an experienced programmer will think. What they'll think is, first of all, "I'm working with unsigned short data", and then "ooh, nice, I'm glad somebody actually thought to mention this is specifically 565 data we're working with." The RGB_565_BYTES_PER_PIXEL has absolutely nothing to do with the data type itself, only that the constant we're using to calculate how much memory we need to calculate is described verbosely, instead of just width * height * 2, or width * height * sizeof(unsigned short).

I'm a serious offender in my texture loading code:


However, the code works fine and is compartmentalized so why make it readable, right?!?!???

daveh84 Wrote:However, the code works fine

Actually, that code is broken. What happens if CGImageGetColorSpace returns greyscale, or paletted?