I noticed before that when I used a 32x32 texture on a mesh object as its texture, there appeared some junk on the texture that should not be there. I'm not sure how to describe it other than, it was pink colored spots that appeared in the phone but not when looking at the texture in Photoshop or Preview.

I swapped it to a 64x64 and it worked fine for that 1 texture so I didn't worry about it.

Now, I have a particle system that I would really prefer to use a 32x32 or even 16x16 texture for the particle. I see the same problem with the 32x32 texture when the particles are rendering. Again, swapping it with a 64x64 texture fixes the problem but with a particle system, I'd be thankful if I could use a lower res texture.

Does anyone know if this is a known limitation with the iPhone as a texture minimum or is there something I can do to make this not happen with a filter or some other technique? Thanks in advance.

Textures should (and I have personally verified that they do) work at 32x32 and smaller, down to 1x1.

I suggest you look at the pixel data you're passing to glTexImage, to verify it is correct before OpenGL gets involved.

arekkusu Wrote:Textures should (and I have personally verified that they do) work at 32x32 and smaller, down to 1x1.

I suggest you look at the pixel data you're passing to glTexImage, to verify it is correct before OpenGL gets involved.

As I said, I verified that the data is correct. I even looked at the values in the buffer before passed to OpenGL.

OK, that wasn't clear from your first post-- looking at it in Photoshop isn't the same thing as inspecting the hex that the image loader gives you.

What format texture are you creating?

If you're sure your input data is correct before GL gets it, and drawing a textured quad produces pink spots, I strongly suggest you file a radar about it.

I do think there's a bug with small textures - I saw the same junk in my small sprites.

I changed my "malloc" call to "calloc" and it went away - it seems like CGBitmapContextCreate doesn't always clear them memory before loading the image in? Try that, then buy me a beer.

Smasher, you're changing your malloc to calloc in the texture loading, I presume. I'm dealing with PNG's. I'll see if changing to calloc helps. If not, I'll look at doing the radar. Thanks!!

Wow, using calloc fixed the problem. I don't understand why.

I've seen the same thing, and from my perspective, it actually makes sense. CGBitmapContextCreate simply takes an array of pixels (and some other stuff) and wraps it in a CGContext; it doesn't know whether or not there's already an image in the array of pixels you pass it, so it dares not clear the buffer. Compositing the pixels from a loaded image file is a draw operation, so it's a blend, not a replace. Transparent parts of your loaded image will then reveal any memory garbage that malloc left for you in the buffer from which you created your CGContext.

This is exactly why I suggested inspecting the bits before you pass them to glTexImage-- it's a problem with the image loading, not with OpenGL.

Yup. I ran into the same bug from using some of the early example code.

My guess is it has a lot to do with how malloc treats small or large allocations differently. Large allocations are going to get new sections of memory, while small allocations are more likely to get an already used section. Just a conjecture, but it sorta makes sense.

I did inspect the bits but I must not have looked at the ugly parts. Anyway, thanks everybody for sharing your wisdom!

Heh, I just ran into this problem a few days ago too, and assumed we were restricted to 64 x 64 (which I thought was weird). Glad to see this came up!