iOS Apple's GLSprite and non-256x256 image

[biosopher]

Does anyone know why GLSprite only works with .png of size 256x256?

I have used the GLSprite code unaltered except for swapping the default png with either a 32x32 or 16x16 image. This results in messed up texture mapping. However if I put in any 256x256 images, the textures map properly.

Is this a problem with GLSprite's image loader or do I somehow misunderstand the way texture mapping occurs for images that are not 256x256 pixels?

Thanks,
Anthony

 

[CommanderData]

OpenGL in general- textures are always a power of two, which means 16x16 and 32x32 are acceptable sizes. I believe you need to study the the GLSprite code more closely to understand your problem...

Just in case you're wondering... I don't see a problem with the loading with my quick read through. My version does retrieve width and height from the spriteImage CGImage. Does yours?

EDIT - one last thought! Are you seeing problems in the Simulator, or on an actual iPhone when you test it???

 

[biosopher]

Thanks for the reply.

It's very odd. I've dug thru the code for a couple hours and don't see where the 256 would be 'locked in'. As you say, the width/height seem to be pulled from the image.

Oddly even more, I've been able to use 64x64 & 128x128 images without a problem. It's only the smaller sizes that cause the image corruption.

It's also not an image format problem as I've created my own 64, 128, and 256 png's without a problem.

 

[xsmasher]

I have used the GLSprite code unaltered except for swapping the default png with either a 32x32 or 16x16 image. This results in messed up texture mapping. However if I put in any 256x256 images, the textures map properly.

Yes, I believe there is a problem with smaller images - or maybe just a bug in the GLsprite sample. I got the same result with small images - some transparent portions had garbage in them.

I fixed it by changing the malloc call to a "calloc" call - that clears the memory before the image is loaded. Now my 16x16 sprites look just fine.

//original call
//spriteData = (GLubyte *) malloc(width * height * 4);
//clear the memory
spriteData = (GLubyte *) calloc(width * height, 4);

Addendum: I guess this is a bug in the GLSprite example. I don't see anything in CGBitmapContextCreate that says it clears the buffer, just that it "creates a context," so I guess we're responsible for clearing the memory before drawing an image with an alpha.

 

[CommanderData]

xsmasher, that makes sense all right~ great find! If the PNGs did not contain alpha transparent sections he would have never noticed it!

It is odd that this appears more obviously/frequently with smaller images, but maybe that's because the iPhone is able to squeeze that smaller malloc'ed memory into more areas... areas that may be polluted with unused bytes.

 

[biosopher]

Thanks xsmasher!

That solved the problem. People at Apple's dev forum thought the limit was 64x64 so I'll pass your info on & enlighten them.

discussions.apple.com/thread.jspa?messageID=7621828

Anthony