Does anyone know why Blend DstAlpha One might be behaving like Blend One One on iPad with ARM7 and OpenGL ES 1.1? I’m surprised to see that the shader behaves differently than on desktops, but doesn’t appear pink.
Some combinations can or are not supported by the iOS OpenGL ES 1.1 emulation in the driver (if you force 1.1 on a 2.0 device the driver will handle the emulation), in which case it falls back to something supported
due to this it also should never become pink
Thanks for the information. Do you know where I can find official documentation for this sort of thing?
For instance, the API specification does not mention such a restriction, nor does the Apple OpenGL ES programming guide. Do you just discover these things by trial and error?
That are the API specs for 1.1
If you are on an ES 2.0 device, then there is no 1.1 technically, there is only “1.1 emulation”, the Programming Guide from apple points that out in the OES 1.1 on SGX block ( “OpenGL ES 1.1 is implemented on the PowerVR SGX hardware using customized shaders.” ), so basically it works like FFP on late SM3 and SM4+ hardware on the desktop which don’t support FFP hw wise anymore either
That being said, the specs normally still are widely correct.
As for how to find these things: Yes normally basing on “great, doesn’t work, so what options do I have left”, what else to do, unless you have sources, it makes only partially sense to sift through specs as you don’t know nor can control whats implemented and how it is setup. Thats at least my stance, sick of hunting phantoms basing on “educated guesses”
In this case I’m unsure if the problem is the blend function you setup itself and not the data it finds in the dest which result in the same as if it was ONE (if the dst is fully opaque at the time, then that would be the expected result, same if the target buffer it renders to just has no alpha channel), because the framebuffer is setup as RGB565, not RGBA8 (which would be the default)
You could test that by changing the corresponding line in CreateWindowSurface of AppController.mm
Hunting for that brought up another question for me to find an answer for in the future (why rendertextures in unity refuse the depth mode, while the create functions there definitely can use it)
That makes sense. Thanks!
No prob, normally its you answering my questions when it comes to this kind of stuff (by having answered to others before and me searching similar answers) 
http://answers.unity3d.com/questions/38065/what-shader-blending-modes-dont-work-on-ios
There was a discussion about this in the 3.2 beta cycle, if you want to check google groups.
Thanks, Jessy. Do let us know if you figure out exactly how to get the frame buffer to include an alpha channel.
The discussion in the “iPhone beta” is titled “Banding with MSAA?”. I described there that all you need to do is change the first occurrence of “RGB565” to “RGBA8”, in AppController.mm, like dreamora said. Nobody was able to tell me what the other instance of “RGB565” does, but I’d probably change it too, just to be safe. Also, nobody answered my question about whether there was any possibility to use a different mode per material. I highly doubt that, but I’d like to know how all-encompassing the write mode has to be.
And I don’t know the figures on this, but keep in mind, you can’t just add a channel. You have to totally double the color data getting written, so it’s probably slow and to be avoided, hence the default being 16 bit color. On the bright side, it will probably look awesome.
You can set it per buffer, the general framebuffer is controlled through above mentioned code, the other buffer you have at hand are Backbuffers which you set yourself to be correct in the constructor / create.
Materials wouldn’t make sense as materials have no color or alike, they are just a set of instructions that define how a set of textures are processed when they are drawn basing on the shaderlab setup cg / glsl program.
The only thing missing at the time is an explicit exposure for textures to define the format yourself, at least RGBA4 RGB565, a corresponding request was made at some point from what I recall.