Divergence Windows7 vs Window10

Version imprimable

24/01/2018, 12h02
Pr1ms

2 pièce(s) jointe(s)

Divergence Windows7 vs Window10

Bonjour à tous,

Je suis développeur depuis longtemps et pour ma culture personnelle je m’intéresse en ce moment à OpenGL.
J'ai suivi les différents tutoriels disponible sur https://learnopengl.com/ afin d'appréhender les bases de la chose. Tout se passait très bien tant que je travaillais sur mon vieux PC sous windows 7.
Seulement voilà, j'ai repris les développements sur une machine windows 10 et là, c'est le drame, plus rien à l'écran. La fenêtre se créée mais reste noire (ou tout du moins de la couleur précisée dans mon glClearColor).

Le site présente un toto complet visant à créer un jeu de casse-briques assez simple, mais qui permet de se frotter à un peu tout (shaders, physique, rendu de texte, musique...).
En revenant sur mes pas, j'ai réalisé que dès le tutoriel sur le rendu du premier Sprite, j'ai l'image suivante sous mon windows 7 et le fond noir uniquement sous windows 10.
Pièce jointe 345023
Si je prend le code obtenu à la fin du tutoriel par contre, j'ai certaines parties de mon application qui s'affichent quand même, à savoir le texte et les effets de particules. Cela me permet donc de cibler le problème.

En gros, j'ai deux façons de faire un rendu :
- soit l'objet a, pour une raison bien précise, ses propres shaders (c'est le cas de mes textes et de mes particules) et gère donc lui même son rendu (appel d'une fonction Draw propre à l'objet dans la boucle de rendu)
- soit l'objet ne possède pas ses propres shaders et là je fait donc appel à une classe de rendu, qui elle en possède, pour gérer l'affichage.

Mon texte et mes particules sont les seules choses répondant à la première catégorie et j'en déduit donc que c'est le processus lié à la seconde qui est problématique sous windows 10, seulement je ne vois pas pourquoi.

Une pièce-jointe valant mieux qu'un long discours, je vous laisse en PJ la version la plus simple (rendu d'une unique sprite), qui fonctionne parfaitement sous windows 7 (voir image plus haut), mais pas sous windows 10.
Pièce jointe 345040

Merci à tous ceux qui ont tenu jusque là sans s'endormir :)
25/01/2018, 09h30
dragonjoker59

Salut!

As-tu activé les extensions de débogage OpenGL, tu ne fais aucun check des erreurs OpenGL qui pourraient arriver.
25/01/2018, 10h25
Pr1ms

Hello dragon,

A priori non. Je suis un peu "jeune" dans l'OpenGL. Peux-tu m'indiquer comment activer ces messages de debug ?

Bonjour,

Alors j'ai un peu avancé. J'ai activé le debug comme suit :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
glfwInit();
[...]
glfwWindowHint( GLFW_OPENGL_DEBUG_CONTEXT, true );
[...]
GLint v;
glGetIntegerv( GL_CONTEXT_FLAGS, &v );
if (v == GL_CONTEXT_FLAG_DEBUG_BIT) {
    std::cout << "OpenGL debug context present" << std::endl;
}
int myData;
glDebugMessageCallback(debugCallback, &myData );

Avec le callback suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
void debugCallback(GLenum source, GLenum type, GLuint id, GLenum severity,GLsizei length, const GLchar*message, GLvoid*userParam)
{
    printf("Message reçu :\n");
    switch (source) {
        case GL_DEBUG_SOURCE_API : printf("    Source : GL_DEBUG_SOURCE_API\n"); break;
        case GL_DEBUG_SOURCE_WINDOW_SYSTEM : printf("    Source : GL_DEBUG_SOURCE_WINDOW_SYSTEM\n"); break;
        case GL_DEBUG_SOURCE_SHADER_COMPILER : printf("    Source : GL_DEBUG_SOURCE_SHADER_COMPILER\n"); break;
        case GL_DEBUG_SOURCE_THIRD_PARTY : printf("    Source : GL_DEBUG_SOURCE_THIRD_PARTY\n"); break;
        case GL_DEBUG_SOURCE_APPLICATION : printf("    Source : GL_DEBUG_SOURCE_APPLICATION\n"); break;
        case GL_DEBUG_SOURCE_OTHER : printf("    Source : GL_DEBUG_SOURCE_OTHER\n"); break;
        default: printf("Source inconnue\n");
    }
    switch (type) {
        case GL_DEBUG_TYPE_ERROR : printf("    Type : GL_DEBUG_TYPE_ERROR\n"); break;
        case GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR : printf("    Type : GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR\n"); break;
        case GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR : printf("    Type : GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR\n"); break;
        case GL_DEBUG_TYPE_PORTABILITY : printf("    Type : GL_DEBUG_TYPE_PORTABILITY\n"); break;
        case GL_DEBUG_TYPE_PERFORMANCE : printf("    Type : GL_DEBUG_TYPE_PERFORMANCE\n"); break;
        case GL_DEBUG_TYPE_OTHER : printf("    Type : GL_DEBUG_TYPE_OTHER\n"); break;
        default: printf("Type inconnu\n");
    }
    switch (severity) {
        case GL_DEBUG_SEVERITY_LOW : printf("    Severite : GL_DEBUG_SEVERITY_LOW\n"); break;
        case GL_DEBUG_SEVERITY_MEDIUM : printf("    Severite : GL_DEBUG_SEVERITY_MEDIUM\n"); break;
        case GL_DEBUG_SEVERITY_HIGH : printf("    Severite : GL_DEBUG_SEVERITY_HIGH\n"); break;
        default: printf("Severite inconnu\n");
    }
    printf("    Message : %s\n\n", message);
}

Tel quel, cela ne compile pas à cause de la signature de la fonction de callback (invalid conversion). Je peux "forcer" une compilation en castant le callback :

Code:

1
2
3
 
int myData;
glDebugMessageCallback((GLDEBUGPROC)debugCallback, &myData );

Cela ne m'avance pas à grand chose :
- sous windows 7, le tout tourne toujours très bien sans le moindre message d'erreur;
- sous windows 10, l'application plante dès le lancement, à l'appel du glDebugMessageCallback.

PS : j'ai les mêmes comportements avec glad et GLEW (je m'étais posé la question au cas où ce soit la gestion des appels OpenGL qui flanche).

Edit : j'ai fini par réussir à lancer mes débugs. J'ai seulement un message et pas du type ERROR :
Message reçu :
Source : GL_DEBUG_SOURCE_API
Type : GL_DEBUG_TYPE_OTHER
Severite inconnue
Message : Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.

29/01/2018, 01h52
Pr1ms

Bonjour,

C'est bon problème résolu. J'ai mis le temps mais j'ai fini par comprendre.
En initialisant une matrice glm::mat4 toto; on récupère une matrice d'identité sous windows 7 mais par contre, c'est une matrice nulle sous windows 10.
Un coup de glm::mat4 toto = glm::mat4(1.0f); et j'ai résolu mon soucis !
29/01/2018, 13h53
dragonjoker59

Et c'est sans recompiler d'une plateforme à l'autre ?
Si c'est le cas, il faudrait tester la dernière version de GLM, et si le problème est toujours là leur remonter le bug.
18/02/2018, 18h55
Natho18

Bonjour, je souhaitais juste apporter un complément d'information.

Alors en effet, le "problème" venait bien de glm et il s'explique du fait que vous utilisez surement la version 0.9.9+ sur W10 et une version antérieure (0.9.8 -) sur W7.
Les développeurs de glm ont décidé de retirer les initialisation par défaut à partir de la version 0.9.9 (considéré comme une amélioration):

Citation:

Improvements:
No more default initialization of vector, matrix and quaternion types

(source: https://github.com/g-truc/glm#improvements)

Du coup, il faut bien faire attention à ça si on met à jour la lib.