Simulator Graphical Glitch *Updated*

Nibbie
Posts: 3
Joined: 2009.11
Post: #1
*note to administrators - please disregard earlier post, as this one contains an extra, small but possibly vital piece of information not in the earlier version*

To make a long story short, I've been doing some iPhone development in college for a class, and for my final project I am developing a simple game using OpenGL. Up until now, I've been using the university computers, but I have recently got my hands upon a friend's macbook that he's letting me use. I've transferred my files over to it, but when I run the simulator, I get these strange graphical artifacts:

On the menu screen, when a subrect image is drawn to screen on top of the background, the background's color coordinates are flipped (technically vertically, because I simply rotated the projection).
[Image: ss1s.png]

Also, in the actual test playing field, there is a different effect - with the bullet particles, strange color warping appears, and on animation tests in the top-left, pure white keeps flickering.
[Image: ss2gms.png]

It is of note that this only occurs in the simulator, and as such I could deal with it if necessary, but it is rather irritating, and I'd rather as much be able to test in the simulator for minor edits.

Some information:
None of these graphical glitches occured in any of the simulators of any of the macs I've used previously
All images are PNGs
All images were created in the same program
All images are of 2** (powers of two)
I am using kCGImageAlphaPremultipliedLast
Images are loaded via UIImage/CGImageRef, copied over into OGL then released (the UIImage/CGImageRef context)
No depth buffer - I handle zsort myself
I am using glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
I have attempted to use GL_ONE, GL_ONE_MINUS_SRC_ALPHA but this made no difference to the glitches except that the particle glitches became more pronounced.
The background image has no alpha channel
The current Macbook OS is Snow Leopard
XCode and the SDK are the latest version, the tests are being done in iPhone OS 3.0
When testing the simulator under iPhone OS 3.1 and 3.1.2, the bullet particle glitch disappears, but the other two glitches remain.
The animation test glitches appear to be that the HUD joystick texture is drawn beneath it at full alpha with the same location and subimage - both animation textures and joystick texture are 256x1128.

I have attempted to search for information on this, but have come across nothing - I am either using improper keywords, or the results are getting buried because this problem is uncommon. Either way, I do not know what is causing this problem, and as such, am seeking help here.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #2
Hopefully one of the OGL gurus around here will pop in and instantly recognize what's up. Otherwise, until then, from my own experience, I would guess: If it's exactly the same program on the MacBook as it is on the school's computers (i.e. you just copied the entire project folder over intact), chances are it was broken before too and you just got lucky that it didn't glitch on the school's computers.

I can't think of anything obvious off-hand that might be causing these issues, but I know it's pretty easy to forget some crucial little state detail. See the OpenGL FAQ for some tips on debugging (specifically the second post).
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #3
1128 is not a power of 2.

1024 is.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #4
I was going to mention that too, but I'm sure it was a typo for 128 Wink

Also, max size is 1024 on iPhone (just as a side-note).
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #5
I cannot tell from your screenshots: are your textures skewed/offset from where you expect, or are the pixels being drawn in generally the right spot (except for extra garbage).

What formats and types are you providing to TexImage2D()

Are you using any kind of glPixelStore() state on the desktop? Many of those options not available in OpenGL ES, and so you might not be detecting the error, and then having GL read the data with a different stride than you intended.

Is your CAEAGLLayer being blended with any other layers, or is the layer opaque? CoreAnimation in the simulator is much less forgiving of illegal premultiplied alpha values (r,g,b > a) than on the device.

If you feel that there is something truly strange going on, you can file a bug with Apple, and attach the Sim version of the test (including buildable source code is ideal).
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2009.11
Post: #6
First off, I'd like to thank you all for your various advice, and yes, it was a typo meant to be 128 pixels, not 1128.

Secondly, I've discovered the problem, and solved it myself after a weird realization.

Apparently, for some versions of OSX, when creating a CGContextRef, the new CGContextRef may not be clear/empty - if there existed a previously-created texture of the same size, the old texture could still exist in video memory, and thus when the new CGContextRef was to be created, the old texture would be underlain beneath whatever new texture was applied. This is unnoticeable when the images contain no alpha - however, with alpha, the underlying texture became visible. Other than this, the CGContextRef could also contain video garbage, hence the bullet particle glitches.

This was easily remedied with CGContextClearRect with each texture created . Of interesting note was that this problem only seemed to crop up in the simulator.

This is something to remember in the future, and hopefully others will not have this problem.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #7
That was my first thought when I saw your bullets, but the other larger stuff didn't fit with that theory. We've known about this for a long time now: that images smaller than 64x64 can get garbage in the alpha channel with using CG to load. The simple fix for that was to replace a malloc with calloc. Something like:

Code:
void *pixels = calloc(width * height * 4, 1);
CGContextRef context = CGBitmapContextCreate(pixels, ...

I don't recall ever seeing that alpha garbage be an issue with images larger than 64x64 though (although maybe it does now with newer versions of OS X? I wouldn't know because I've been using calloc since like July of last year...).
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2009.11
Post: #8
Actually, the bullets are part of a 256x256 sheet, but yeah - it may be a Snow Leopard specific problem, as the two macs that I saw this error on were both running it - all others I've tested from a) displayed no error and b) hadn't been upgraded to Snow Leopard yet.

Anyhow, I must get back to work. And I will keep calloc in mind - seems a useful bit of knowledge.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #9
Out of curiosity I just tested replacing my callocs with malloc and sure enough, I got garbage all over the place in my alphas. I'm on Snow Leopard, using the 3.1.2 SDK. So I don't know specifically if it's the SDK or Snow Leopard, but my guess is that it's some sort of an "optimization" built into Snow Leopard that it doesn't automatically clear the alpha bits on load.
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #10
AnotherJake Wrote:Out of curiosity I just tested replacing my callocs with malloc and sure enough, I got garbage all over the place in my alphas. I'm on Snow Leopard, using the 3.1.2 SDK. So I don't know specifically if it's the SDK or Snow Leopard, but my guess is that it's some sort of an "optimization" built into Snow Leopard that it doesn't automatically clear the alpha bits on load.

It isn't an optimization, it is a flat-out bug in the application code.

Malloc is not guaranteed to return zeroed memory at all. You were just getting (un)lucky that it turned out that way most of the time.

CG's default blending state is to blend the image into a CGContext.

When you wrap non-zeroed memory in a CGBitmapContext, and then draw to that context with a CGImage, using the default blend state, you're blending with garbage.

What changed was that malloc is more likely to return non-zeroed memory. But, the application bug is just as real on any version of the OS, and on the Sim and Device as well.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #11
Frogblast Wrote:It isn't an optimization, it is a flat-out bug in the application code.

Malloc is not guaranteed to return zeroed memory at all. You were just getting (un)lucky that it turned out that way most of the time.

Well, I know darn well malloc doesn't zero data; that's why there's calloc. Wink

The "flat-out bug" in my application code was based off of sample code previously provided by Apple for iPhone. The perception was that CG zeroed the data, not malloc.

I wasn't aware that CG behavior is (*apparently*) correct now and that it wasn't previously (because of a change in malloc, as you mention). There have been countless posts on this very subject over the last 18 months where others have observed the same behavior.

[adding] This is good information to know because I, and apparently most others, haven't taken the time to weed through the CG docs with a fine-tooth eyeball and were relying on sample code instead Wink
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Updated to SDK4, CADisplayLink layer now sized wrong on iPad michaeltoy 6 4,846 Jul 19, 2010 12:39 AM
Last Post: Madrayken
  Strange Graphics Glitch - Buffers Lostlogic 0 1,757 Oct 10, 2008 05:17 PM
Last Post: Lostlogic