Voici la transaction: Si je laisse le code avec Est-ce que je manque quelque chose? code ci-dessous: Glgenbuffers (1, Vertexbuffers) , le code compile et fonctionne. Mais, je pensais que cela devrait être 2 car vertexbuffers est de taille deux.
3 Réponses :
En supposant que Vertexbuffers code> est déclaré comme: glGenBuffers (2, vertexBuffers);
Je comprends votre commentaire. Cependant, les verxbuffeurs sont de taille 2, mais dans mon code, j'ai ceci: Glgenbuffers (1, Vertexbuffers) et le programme fonctionne. Si je change le 1 à 2, il ne présente plus le triangle.
Si vous regardez la réponse de Tim ci-dessous, il explique pourquoi cela fonctionne même lorsque vous ne générez pas les deux tampons. C'est une quirk de la façon dont OpenGL fonctionne, mais ce n'est probablement pas ce que vous vouliez.
L'objet actuel n'est créé que lorsque vous appelez Donc, si vous créez simplement une gamme d'entiers aléatoires, aussi longtemps que Aucun d'entre eux se chevauchent, vous pouvez l'utiliser comme liste de tampons sans appeler Un peu de démonstration: glgenbuffers ne fonctionne pas tout à fait comme ce que vous attendez. Lorsque vous appelez glgenbuffers , il n'est pas réellement créer rien. Il renvoie simplement une liste d'entiers qui ne sont actuellement pas utilisés comme noms de mémoire tampon. GLBindbuffer . Vous pouvez donc simplement créer un entier que vous aimez et le transmettre à GLBindbuffer et qu'un tampon valide sera créé à cet indice. Glgenbuffers n'est en fait pas requis du tout, il est juste là comme une fonction de commodité pour vous donner un entier inutilisé. Glgenbuffer . C'est pourquoi votre code fonctionne si vous dites à Glgenbuffers de créer 1 ou 2 tampons. Tant que vous avez deux tampons avec deux noms différents, peu importe l'endroit où l'entier est venu.
Dans plus récent OpenGL Glgenbuffers est requis AFaik.
En outre, Isbuffer devrait revenir en true en fonction de la spécification: retourne true si la mémoire tampon est le nom d'un objet tampon. Si la mémoire tampon est zéro ou si la mémoire tampon est une valeur non nulle qui n'est pas le nom d'un objet tampon, Isbuffer retourne false.
SPEC sur GLGENBUFFERS Exigence: Une erreur invalide_opération est générée si la mémoire tampon n'est pas nulle ou un nom renvoyé à partir d'un appel précédent à Genbuffers ou si un tel nom a été supprimé avec Deletebuffers
Hmm, je n'étais pas au courant qui avait changé. En regardant la page manuelle de glisbuffer, je vois un nom renvoyé par Glgenbuffers, mais pas encore associé à un objet tampon en appelant GLBindbuffer, n'est pas le nom d'un objet tampon. , qui semble être en désaccord avec les autres déclarations.
@Killiants ressemble à cela pourrait avoir changé dans la version 3.2, pour le profil principal. Merci de l'avoir apporté à mon attention. Changelog: Linderbuffer (Section 2.9.1), Bébéqueur (section 2.15) et BindTexture (section 3.8.1) pour générer uniquement des erreurs pour les noms générés par l'utilisateur dans le profil principal
AFAIK, Genbuffers lève les yeux x quantité d'identifiant de tampon qui ne sont actuellement pas utilisées et ne les renvoie pas sous la forme d'un ID entier (ou d'un tableau d'entiers si vous en avez généré plus d'un).
Comme l'a dit OP, vous solidifiez ce contrat en liant ces identifiants à ces tampons réels. En d'autres termes, vous associez l'identifiant avec les tampons réels en les liant. N'oubliez pas que ces identifiants ne sont pas libérés pour les appels de Genbuffer ultérieurs, à moins que vous ne les supprimiez explicitement à l'aide de Deletebuffer.
Je pensais cela hier, je dois faire un GLBindbuffer (GL_ARRAY_BUFFER, 0) après chaque GLBUFFERDATA (...).
Quelle est la déclaration de
vertexbuffer ?@Jwwnalker, je mentionne que les verxbuffeurs sont de taille de taille deux.