Texture Minimum

Member
Posts: 241
Joined: 2008.07
Post: #1
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.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #2
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.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #3
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.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #4
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.
Quote this message in a reply
Member
Posts: 27
Joined: 2008.12
Post: #5
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.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #6
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!!
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #7
Wow, using calloc fixed the problem. I don't understand why.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #8
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.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #9
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.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #10
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.

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
Member
Posts: 241
Joined: 2008.07
Post: #11
I did inspect the bits but I must not have looked at the ugly parts. Anyway, thanks everybody for sharing your wisdom!
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #12
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! Smile
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Minimum Spec 2nd Hand Machine for IPhone dev mrtrombone 2 2,683 Aug 4, 2008 06:06 PM
Last Post: mrtrombone