Upgraded to 10.6, XCode 3.2.1 -- OpenGL broken

Nibbie
Posts: 3
Joined: 2010.02
Post: #1
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:
[Image: screenBefore.png]

After update:
[Image: screenAfter.png]

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.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #2
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?

Code:
colorSpace = CGColorSpaceCreateDeviceRGB();
pixels = calloc(width * height * 4, 1); // <-- ** NOTE ** must use calloc instead of malloc or alpha can be filled with garbage
context = CGBitmapContextCreate(pixels, width, height, 8, 4 * width, colorSpace, kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big);
CGColorSpaceRelease(colorSpace);
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2010.02
Post: #3
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?
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #4
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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
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.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #6
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 Rasp
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #7
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.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2010.02
Post: #8
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
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  OpenAL, i am doing it wrong or is it broken on iPad simulator? AdrianM 3 3,971 Apr 23, 2010 11:18 AM
Last Post: Rasterman
  broken pipes kendric 0 1,650 Jun 7, 2009 09:09 PM
Last Post: kendric