Hi everyone, this is my first post, and I'm posting because I can't find a solution to this problem.

I upgraded to Snow Leopard, and downloaded the new SDK (with xcode 3.2.1) and now all of my apps-in-progress that use OpenGL draw multiple times per sprite:

Before update:


After update:


I can't track it down at all, when I draw an array that draws a single rect, after binding a single texture, I get two rects with two different textures. I'm really totally stumped as nothing has changed in my opengl class.

Does anyone know what would cause this problem, or have any experience addressing it? Thank you.

What are you using for texture loading? If you're using core graphics, you'll probably need to clear your bitmap. Something like this look familiar?

Quote:What are you using for texture loading? If you're using core graphics, you'll probably need to clear your bitmap. Something like this look familiar?

Yes, and thank you! I was using that method, but I was using malloc instead of calloc, I changed this and my problem was immediately fixed, so thank you.

Do you know why it never caused a problem until the update?

MonsterFerg Wrote:Do you know why it never caused a problem until the update?

Nope. Only Apple knows. The behavior now is actually the correct behavior according to the documentation. Apparently it was always supposed to be like this, but for whatever reason it wasn't, except for images 64 x 64 or smaller in previous versions. Unfortunately even Apple's own sample code used malloc, so there have been lots of folks getting tripped up by this -- myself included.

malloc on Mac OS X will return a cleared block if the size is larger than a certain threshold (at which point it goes to the VM system for the memory, which always returns zeroed memory for security reasons). The threshold is entirely arbitrary, and entirely likely to change with each OS release.

valgrind, or the environment variable MallocScribble can help detect these errors.

OneSadCookie Wrote:malloc on Mac OS X will return a cleared block if the size is larger than a certain threshold (at which point it goes to the VM system for the memory, which always returns zeroed memory for security reasons). The threshold is entirely arbitrary, and entirely likely to change with each OS release.

Huh... I was totally unaware of that. That could definitely explain the change in behavior.

Another way of avoiding this error would have been to ignore the sample code and actually read the documentation

I too had to fix this issue from the incorrect Apple sample code, though a long long time ago. I knew it was a memory allocation issue, but I didn't realize that the reason you get zeroed memory was because it was a security thing. Interesting.

OneSadCookie Wrote:malloc on Mac OS X will return a cleared block if the size is larger than a certain threshold (at which point it goes to the VM system for the memory, which always returns zeroed memory for security reasons). The threshold is entirely arbitrary, and entirely likely to change with each OS release.

valgrind, or the environment variable MallocScribble can help detect these errors.

Ahh, good to know.

Well now I know why 32x32 textures would always end up noisy. I just figured it was some OpenGL ES limitation, which didn't bother me since for textures that small I usually have a grid of them on one 128 or 256.

Cheers