Problème d'initialisation en Release/Debug sur différents PC

Bonjour,

Je développe mon propre moteur 3D, qui commence à être conséquent même s'il est loin d'être fini.

Jusqu'à présent je le développais et effectuais mes tests avec un pc ayant une carte NVidia (GeForce FX 5600), je n'avais aucun problème.
Ayant changé de PC avec maintenant un GPU ATI (HD 5750) je me suis rendu compte que le moteur compilé avec mon ancien PC se charge correctement, charge les meshes correctement, mais n'affiche strictement rien. Il n'y a cependant aucune erreur (un appel de glGetError après chaque directive OpenGL pour vérifier).

Encore plus fort : après avoir recompilé mon moteur sur mon nouveau PC avec le même Visual Studio qu'avant et sans avoir touché ni au code ni aux librairies attenantes, ça fonctionne correctement sur mon nouveau pc mais pas sur mon pc au taf (qui a un GPU NVidia).

On monte encore d'un cran : j'ai voulu faire tester mon moteur à un développeur ayant une machine avec une carte graphique ATI Radeon 7000 et quelque soit la version que je lui passe (compilée sur ATI ou compilée sur NVidia) il rencontre le problème de n'avoir aucun affichage sans avoir d'erreur

Quelqu'un a-t-il une idée pour m'aider dans mes recherches sur ce bug ? Parce que là on est un peu (complètement) perplexes.

Bienvenue dans le monde merveilleux d'OpenGL.

Je te conseille de cibler précisément les cartes sur lesquelles tu voudrais que ton moteur marche ou pas, sans être trop ambitieux. Achêtes toi d'occasion la carte minimum pour chaque vendor, ATI et NVIDIA voir Intel si tu es courageux (grand max 30€ d'occasion).

A l'heure actuelle je te dirais de prendre pour cible les cartes au dessus de Geforce 8 / ATI HD 2400, mais tu veux peut-être faire mieux. Supporter les ATI en dessous des R600 est super pénible. Les drivers sont buggés et ne seront jamais réparés.

En général NVIDIA est trop laxiste alors qu'ATI implémente mal la spécification. Intel je préfère ne pas en parler.

Ensuite prends toujours les derniers drivers mais ne change pas trop souvent non plus car quelque chose casse souvent à chaque driver. Attends que les autres prennent ce risque pour toi.

Inspire toi du code de Ogre3D qui est passé par là lui aussi. Par exemple pour la création de texture il vaut mieux ne pas utiliser les texture NPOT (oui, même si la carte dit qu'elle les supporte, en fait pas vraiment), et créer chaque niveau de mipmap un par un.

Essaye de bien comprendre la séparation entre l'état Sampler et l'état Texture, si tu utilise les multi-textures.

Utilises les glGet dans tout les sens et doute de tout, et éventuellement tu trouveras la compatibilité. Tu peux vouloir vérifier les codes d'erreurs partout, mais si le driver plante ca ne sert à rien :aie:.

Si tu veux que ca marche vraiment partout avec moins d'effort, ben heu... reste en fixed function mais ca sera moche.

Arrivé là tu comprendras pourquoi le seul jeu indie OpenGL avec du postprocessing digne de ce nom a été fait par un mec de l'ARB. :zoubi:
http://www.quelsolaar.com/opengl_performance.txt
FEAR

En ce qui concerne ton problème, ca pourrait-être :

- le niveau de mipmaps que tu veux sampler n'existe pas vraiment, n'a pas été créé
- tu utilise un sampler wrappé dans une struct dans un shader GLSL
- tu n'appelle pas glEnable(GL_TEXTURE_2D); pour activer tes samplers (tu croyais que ca ne servait qu'en fixed function ? eh bien non).

Bon, en tout cas ce n'est aucune des 3 solutions que tu proposes vu que même une primitive non texturée n'est pas affichée...
Je crois que je vais devoir m'amuser à m'acheter de vieilles cartes graphiques ^^

Ça semble pointer vers un problème de ton côté, ce n'est pas parce qu'un code buggué marche "par accident" sur une machine qu'il marchera partout et tout le temps.

Bref, essaie de partir des tutoriaux simples, dont tu as la garantie qu'ils marchent partout (ou du moins sur toutes tes machines cibles) et compare avec ta solution et vois là où tu diverges.

Bonne chance,
LeGreg

Ouai le mieux c'est de se fixer le type de carte minimum pour faire tourner son programme et de l'acheter pour faire ses tests dessus, je dirais de préférences une ATI qui sont beaucoup moins souples et qui t'imposeront la rigueur. Tu as plus de chances que si ton programme marche sous ATI il marchera sous nVidia que l'inverse. Après pour résoudre ton problème alors que ton moteur est déjà bien avancé je te souhaite bonne chance :P
Essaye de faire des trucs vraiment minimalistes pour vite détecter les erreurs d'incompatibilités.

Merci pour vos réponses, je pense que je vais suivre le conseil de LeGreg et repartir de code simple...

Je reviens vers vous, toujours avec le même problème, mais avec des avancées sur le ciblage.
En fait j'ai réussi (je pense) à le reproduire sur ma machine, mais c'est assez déconcertant.
Je compile donc avec Visual Studio.
En Debug, en le lançant avec Visual Studio ou directement en double-cliquant sur l'exe, tout va bien.
En Release, en le lançant avec Visual Studio, je n'ai pas de problème, par contre en double-cliquant sur l'exe le problème apparaît.

Le fait de lancer avec Visual Studio, qu'est-ce que ça change ? Il initialise des variables ? Il met en place un environnement de debug (je suis en release et il me dit bien que je n'ai pas compilé avec des infos de debug, j'ai bien linké avec les libs en release) ?

Le problème apparait c'est à dire ? un erreur d'affichage comme au début ?
Une erreur de dll, de fichier non trouvé ? peut être n'as-tu pas choisis le bon répertoire de travail pour visual studio.

Bonjour,

Vu que le problème intervient de façon aléatoire suivant la machine et jamais en débug, je dirais effectivement que c'est un problème d'initialisation de variable, ou une écriture en fin de tableau.

A vérifier avec "Application Verifier"

Pour l'initialisation de variable...maintenant il faut chercher :?
Le seul moyen que je vois, c'est de loguer les différentes parties importante du programme et de regarder qu'est ce qui ne s'exécute pas en release.
Ou d'accrocher le déboguer sur le programme lors du crash.

Ou d'initialisation tout court d'ailleurs... (contexte, GL, ... etc.)

Je t'aurais bien conseillé Valgrind... mais avec Windause Visoual :aie:

Log un maximum et utilise le debugger de Visual!...

Le problème est bien celui ou tout semble aller correctement mais il n'y a pas d'affichage.

En même temps je n'ai pas encore terminé la partie "création de fenêtre compatible OpenGL" sous Linux, donc j'avance sous Windaube...

Ca n'est en tout cas pas un problème de dll, le programme ne se lancerait pas si c'était le cas.

Accrocher le debugger pendant le crash ne m'est pas très utile, j'ai compilé en release, et l'assembleur n'est pas mon fort.

En tout cas, merci pour vos réponses, je crois que je vais logger comme un malade ^^'.

Le seul truc different que fais Visual quand tu lances l'exe dedans c'est de changer le repertoire par defaut. Verifie quel repertoire par defaut tu as dans VC++. Peut-etre que quelque chose essaie d'acceder a un fichier en path relatif et qu'il ne balance pas d'erreur s'il ne le trouve pas.

Tu peux verifier la non initialisation de variables avec cppcheck:

http://sourceforge.net/apps/mediawik...itle=Main_Page

Il donne aussi quelques autres warnings tres cools.

Verifie aussi que les bonnes dlls sont chargees avec dependencywalker:

http://www.dependencywalker.com/

Dans tous les cas, ce probleme est surement du a un code qui ne check pas une erreur. Il faut toujours balancer une erreur, un crash, ou quoi que ce soit quand y'a un soucis, toujours verifier les codes d'erreurs des APIs que tu utilises, etc. Meme si ton application a des risques de crasher plus souvent, au moins tu ne perdras pas des heures...

As-tu aussi verifie les sorties standards de ton programme? stdout et stderr? Peut-etre qu'une lib que tu utilises envoie un message d'erreur dans stderr par exemple? Certaines applications redirigent les entrees standards et parfois cela t'empeche carrement de les voir dans la console... Il faut alors reforcer la direction vers toi pour pouvoir recuperer les messages, je ne me souviens plus comment faire mais c'est explique sur le net.

Dernierement, tu peux toujours attacher ton debugueur en release. Pour cela, il faut que tu forces la generation des symboles et que tu desactives les optimisations. Ainsi le debogueur fonctionnera correctement meme en release. Essaie d'ailleurs de desactiver les optimisations pour voir si le probleme ne vient pas de la.

Citation:

---

Envoyé par dragonjoker59

Windaube

---

ça par contre c'est pas obligé ... reste sous linux si tu peux pas blairer windows ><

Ce n'est pas que je ne peux pas le blairer (je ne m'en servirais pas sinon), c'est juste une habitude d'écriture. Je n'avais pas l'intention de troller. Il est cependant vrai que je préfère Linux (raisons personnelles qui n'ont pas lieu d'être exposées ici)

Citation:

---

Envoyé par TanEk

Le seul truc different que fais Visual quand tu lances l'exe dedans c'est de changer le repertoire par defaut.

---

Ca dépend comment tu lance.
Si tu fait F5, c'est un peu comme en debug, ça lance l'exe mais dans un environnement contrôlé. Y as donc certain problème mémoire qui passe inaperçus.

Si tu ctrl+F5 la oui il lance l'exe comme un double click.

Par expérience, vue ce que tu dit, y as de forte chance que c'est un dépassement de mémoire sur un tableau plutôt qu'un problème de pointeur non initialisé.
J'ai souvent eu ce problème avec des tableaux de char du type

Citation:

---

char path[256]

---

et ou le path est un peu > à 256

Citation:

---

Envoyé par dragonjoker59

Le problème est bien celui ou tout semble aller correctement mais il n'y a pas d'affichage.

---

Pars des exemples simples qui marchent et regarde ce que tu fais différemment..

Je me répète mais..

LeGreg

Bon, j'ai corrigé le problème sur mon pc de taf, il s'agissait en fait de 2 erreurs :
- une erreur d'initialisation de variable (visibilité d'un scene node) qui faisait que le root node n'était pas affichable.
- une erreur qui vient de je ne sais où, il n'initialisait pas ma fenêtre d'affichage en release uniquement (le booléen d'init était mis à true, vraisemblablement parce qu'une première frame a été dessinée avant l'initialisation de la fenêtre 8O )

Il me reste à tester ça chez moi et à passer l'exécutable à la personne qui m'a aidé à découvrir ce bug.
En tout cas je vous remercie pour vos conseils et je vous tiens au courant de l'évolution de mon moteur ^^.

Bon, après test chez la personne chez qui le bug apparaissait, je peux marquer ce sujet comme résolu ^^