2017-02-07 7 views
0

J'ai téléchargé cet exemple de code Apple GLEssentials sample code. Je veux effectuer quelques expériences avec le tampon de profondeur, donc au début j'ai décidé de vérifier BUFFER_BITS.OpenGLES 2.0 bits de tampon de profondeur incorrecte

I ajouté le code suivant à OpenGLRenderer.m dans -initWithDefaultFBO méthode:

// code from sample 
NSLog(@"%s %s\n", glGetString(GL_RENDERER), glGetString(GL_VERSION)); 

// buffer bits check 
GLint depthBits; 
glGetIntegerv(GL_DEPTH_BITS, &depthBits); 
printf("depthBits: %d\n", depthBits); 

j'avais prochaine sortie:

GLEssentials[3630:112826] Apple Software Renderer OpenGL ES 2.0 APPLE-12.4.2 
depthBits: 24 

mais ES2Renderer.m je vois la ligne suivante:

// using 16-bit depth buffer 
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, backingWidth, backingHeight); 

Pourquoi c'est arrivé? Est-ce bug?

PS: J'ai testé seulement dans le simulateur iOS, parce que je n'ai pas l'appareil ios.

Répondre

1

Le spec dit:

Une implémentation OpenGL ES peut modifier sa répartition de la résolution des composants internes en fonction de tous les paramètres de RenderbufferStorage (sauf cible), mais l'attribution et choisi le format interne ne doit pas être fonction de tout autre état et ne peut pas être changé une fois qu'ils sont établis. La résolution réelle en bits de chaque composant de l'image allouée peut être interrogée avec GetRenderbufferParameteriv.

Donc, fondamentalement, OpenGLES est autorisé à choisir une profondeur de bits différente de ce qui a été demandé.

Je suppose que sur le périphérique, un véritable tampon de profondeur de 16 bits serait utilisé.

+0

Merci pour la spécification de lien OpenGLES, je suis totalement oublié. – frankWhite