PNG alpha problem OGLES

Member
Posts: 269
Joined: 2005.04
Post: #16
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.

Code:
enum {
    FOUR_BYTES_PER_PIXEL = 0
};

memset(textureData, 0, (texWidth * texHeight * FOUR_BYTES_PER_PIXEL));

Wink
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #17
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:
Code:
enum {
    FOUR_BYTES_PER_PIXEL = 4
};

Might as well define some more while you're at it:
Code:
enum {
    ONE_BYTE_PER_PIXEL = 1,
    TWO_BYTES_PER_PIXEL,
    THREE_BYTES_PER_PIXEL,
    FOUR_BYTES_PER_PIXEL
};
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #18
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 ?
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #19
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 ?

Code:
enum {
    RGB_565_BYTES_PER_PIXEL = 2
};
Ninja
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #20
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.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #21
LOL

ha ha ha ha ha ha

LOL
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #22
AnotherJake Wrote:
Code:
enum {
    RGB_565_BYTES_PER_PIXEL = 2
};
Ninja

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.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #23
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.
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #24
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:
Code:
unsigned short *pixels = (unsigned short *)malloc(texWidth * texHeight * RGB_565_BYTES_PER_PIXEL);

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));

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.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #25
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 Wink All I've (we've) been saying is that it isn't any better than
Code:
unsigned short *pixels = (unsigned short *)malloc(texWidth * texHeight * 2);
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).
Quote this message in a reply
Member
Posts: 35
Joined: 2009.01
Post: #26
I'm a serious offender in my texture loading code:

Code:
size_t width = CGImageGetWidth(textureImage);
size_t height = CGImageGetHeight(textureImage);
        
GLubyte *textureData = calloc(1, width * height * 4);
        
CGContextRef textureContext = CGBitmapContextCreate(textureData, width, height, 8, width * 4, CGImageGetColorSpace(textureImage), kCGImageAlphaPremultipliedLast);

However, the code works fine and is compartmentalized so why make it readable, right?!?!??? Wacko
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #27
daveh84 Wrote:However, the code works fine

Actually, that code is broken. What happens if CGImageGetColorSpace returns greyscale, or paletted?
Quote this message in a reply
Post Reply