Zeross a raison, il est difficile d'avoir un environnement de développement qui fonctionne, mais une fois que c'est bon, tu peux te concentrer sur le contenu, et là, je ne pense pas que tu seras déçu.
 
Je suppose que tu travailles sous Windows (sous Linux, les problèmes sont un peu moins gros avec la plupart des distributions qui installent ça très bien). Je ne connais pas Dev-C++, donc je vais avoir du mal à te donner des conseils (pour ma part, j'utilise cygwin avec gcc/g++ sous Windows pour le développement, ça marche plutôt bien, et la plupart des trucs s'installent d'eux-même).
 
Il semblerait que tu ne sois pas tout seul avec ce problème avec Dev-C++. Certains l'ont résolu en allant dans le menu projet, 'project options', onglet 'general', et en mettant Win32 GUI comme type d'application.
 
Par ailleurs, comment compiles-tu ton programme ?
 
Si c'est fait semi-automatiquement, vérifie que glu32, glut32 et opengl32 sont présentes dans la liste de fichiers à lier à ton programme (dans Linker options, semble-t-il, sous Dev-C++... "-lglu32 -lglut32 -lopengl32" )
 
Si tu le fais en ligne de commande, il doit apparaître les librairies OpenGL et Glut, et l'ordre a parfois une importance (mêmes chaîne qu'au-dessus à mettre dans la directive de compilation pour la phase de liaison)
 
Bon courage, et n'hésite pas à revenir chercher de l'aide, ce serait dommage de s'arrêter à ce genre de problèmes techniques qu'on oublie par la suite (enfin pas toujours, parce que ça continue à merder de temps à autre parce que les librairies ne sont pas dans le bon ordre ou compilées de la bonne façon, c'est parfois à s'arracher les cheveux pour avoir seulement un truc qui compile).

Il me semble que Dev c++ a un gestionnaire de package et qu'il suffit de choisir le package Opengl pour le retrouver installé comme il faut et utilisable directement (lors de la création d'un nouveau projet, il faut choisir un projet de type Opengl)
 

Félicitations !
 
Maintenant, tu n'as plus qu'à t'amuser avec. Et si quelque chose n'est pas clair (même si les tutoriels NeHe sont excellents, c'est en grande partie comme ca que j'ai appris moi-même), tu sais où tu peux venir poser tes questions...
 

Si ca compile, elles y sont. Et ne t'inquiète pas pour glut, d'une part tu n'en aura pas forcément besoin (c'est surtout un gestionnaire pour dessiner la fenêtre et gérer le clavier, mais si tu as autre chose, ce n'est pas utile... pour ma part, j'utilise souvent SDL si c'est un petit programme OpenGL sans interface et FLTK si je veux des boutons et des contrôles de partout ), et d'autre part, j'ai rarement vu OpenGL installé sans Glut, donc je suis persuadé que c'est bon si tu en as besoin.

Désolé pour la latence... Pour information, c'est pour ce genre de chose que j'évite les versions francisées des logiciels. Parfois les traductions sont mauvaises ou curieuses, et ca n'est pas facile de trouver de l'aide. (je ne sais plus quelle était la versions francaise de Broken pipe, mais il m'avait fallu un moment pour comprendre)
 
Est-ce que tu peux détailler les onglets que tu as ? Je n'ai pas moyen d'installer le soft actuellement, donc je suis un peu aveugle. Je pense que la meilleure chose à faire, c'est de chercher la case où sont indiquées les autres librairies à lier au projet, comme opengl32.lib, etc. Pour le "all configurations", c'est peut-être moins important.

Si tu ne trouves pas rapidement, je l'installerai sur ma machine... même si dans la mesure du possible, j'aimerais éviter de le faire (je ne sais pas comment il gèrerait les conflits avec MingW et Cygwin pré-installés)
 
Sinon, la langue, c'est un fichier supplémentaire, sans doute, si tu as réinstallé le logiciel par dessus, il doit encore être présent, d'où le logiciel en français.

Ce n'est pas un très gros problème (de toute façon, par acquis de conscience, je devrais tester, d'autant que j'ai toujours pour projet de développer ma propre interface de développement, c'est bon pour avoir des idées).
 

Ah oui, effectivement, du coup, c'est plus clair. Donc tu n'as juste qu'à ajouter glaux dans les librairies avec opengl32, glut32 et cie pour que ça fonctionne. Ca marche ?

Sisi, il y a bien sûr moyen de mettre un fond d'écran 2D derrière une scène 3D et sans passer par des textures. Heureusement d'ailleurs ! Ca permet aussi de mettre des indications à l'écran au premier plan, comme des barre de vie, un hud, etc.
 
Je m'en suis aussi servi en vision : tu mets ce que voit la caméra derrière (une image, donc) et tu places l'objet 3D dont tu as déterminé la position devant. Si ça colle, alors c'est que l'algo de vision fonctionne
 
 
Je te conseille la démarche suivante :
* en préparation : charger l'image BMP dans un buffer
* pour le tracé :
- effacer l'écran et le Z-buffer
- désactiver l'éclairage, le Z-buffer, etc. mettre la couleur à blanc (sinon l'image est multipliée par la couleur courante, si ma mémoire est bonne, ce qui permet des effets d'ailleurs)
- placer les matrices de projection afin de dessiner le fond (mode 2D)
- se mettre dans un coin de l'écran avec glRasterpos2i(x,y)... en principe en haut à gauche ou en bas à gauche*
- indiquer dans quel sens on trace* avec glPixelZoom(1,1) ou glPixelzoom(1,-1)
- dessiner l'image avec glDrawpixels(largeur, hauteur, format=GL_BGR ou GL_RGB, type=GL_UNSIGNED_INT, pointeur vers le début de l'image)
- réinitialiser les deux matrices de projection, et les placer dans ton point de vue 3D à coup de glOrtho, glLookat, ou je ne sais quoi
- réactiver l'éclairage, le Z-buffer, tout ce que tu as besoin
- dessiner ton objet 3D normalement
 
J'ai du code tout prêt pour ça si tu veux, mais je ne peux pas te le sortir en dix minutes... Je vais regarder.
 
* Pourquoi en haut ou en bas, et pourquoi le zoom -1 ? Ben pour une raison très conne : les BMP, contrairement à la plupart des formats, sont dessinés de bas en haut. Donc selon le fichier utilisé, soit tu te mets en bas à gauche et tu montes, soit tu te mets en haut à gauche et tu descends. C'est probablement le truc qui merdoira le plus, ce que je te suggères vivement, c'est de te mettre au milieu, de lancer le tracé, et de voir comment il faut mettre le zoom et le point de départ à partir du résultat.

D'après ce que m'a raconté un spécialiste de ce genre de choses, et si j'ai bien compris, les display lists ne sont plus trop la façon de faire à la vogue. Cela dit, ça reste bien pratique quand même, et je ne me souviens plus de ce qu'il faudrait mettre à la place...

Ah ben en fait, je n'ai pas eu à chercher beaucoup... Bon, il y a des tas de variantes, mais ça pourra sans doute te servir de point de départ... A noter que si l'image n'a pas la taille du fond, on peut facilement la redimensionner automatiquement en jouant sur les projections.
 
PS : je n'ai pas contrôlé le code, ça vient d'un programme pris au hasard, donc je crois que ça marche, mais ce n'est pas rigoureusement garanti... C'est juste le bout pour tracer l'image de fond. A noter que le premier bloc sauvegarde la projection courante, et le dernier la restaure...
 

Ah, j'avais peut-être mal compris ce qu'il voulait, alors, à partir de son premier message ?
 

Ca date bien de trois-quatre ans, justement. Le hic, c'est que je ne sais plus pourquoi. Je me souviens que je n'arrivais pas à faire fonctionner un truc, et en allant le voir (un vrai spécialiste, même Microsoft a essayé de lui mettre la main dessus... C'est toujours bien pratique ), il m'avait dit qu'on n'utilisait plus vraiment ce genre de choses dans la mesure où ce n'était plus accéléré correctement. Ca avait un sens à une époque où des séquences de commandes pouvaient être optimisées si connues à l'avance, mais pour je ne sais plus quelle obscure raison on procédait différemment à présent.
 
Cela dit, comme c'est pratique, ça m'arrive encore de les utiliser...

Du temps à perdre, non, mais un coup de main, ce n'est pas un problème.
 
Je crois que tu as mal compris ce que faisait glGenTexture... ça crée une structure de donnée en mémoire pour ranger une texture, et ça te fournit des identifiants (des entiers non signés) pour y accéder.
 
Le deuxième paramètre de glGenTexture doit être un pointeur vers un ou plusieurs entiers (Gluint) et non vers les données de l'image (AUX_RGBImageRec). C'est ce que te dit le message d'erreur.
 
Compare :
 

 
avec ce qu'il y a au-dessus :
 

 
Une fois que tu as créé de la place pour les textures, il est temps de les charger :
 

- tu charges l'image dans la structure AUX_RGBmachintruc dans texture1
- tu sélectionnes la texture 0 (en utilisant l'identifiant que OpenGL a rangé dans le tableau texture après l'appel à glGenTexture)
- tu précises les paramètres d'interpolation si elle est trop petite ou trop grande (NEAREST, c'est moche mais rapide)
- et enfin, tu charges l'image dans la texture avec glTexImage2D (la texture étant rangée dans la structure texture1, dans ->data)
 
A partir de là, si ma mémoire est bonne, tu peux d'ailleurs désallouer texture1.
 
Plus clair ?

Non, c'est standard et courant. On fait des trucs bien plus rigolos, d'ailleurs
 
Par exemple, si tu veux dessiner uniquement les contours d'un objet :
- tu desactives l'écriture des données (!)
- tu dessines l'objet (rien n'est affiché, mais le Z-buffer est modifié et du coup l'espace est "occupé" par un objet invisible
- tu réactives l'écriture des données
- tu passes en mode fil de fer
- tu augmente la taille des traits
- tu lui dit de ne dessiner que les triangles qui pointent... vers l'arrière (re-!) (front-culling)
- tu redessine l'objet une seconde fois
...
et magiquement, tu vois uniquement les contours de l'objet. C'est ce qui est utilisé pour le rendu qu'on qualifie (à tord) de cell shading (à ceci près qu'on ne dessine pas un objet invisible, on le dessine en bricolant l'éclairage, en mixant une texture 2D avec la texture de l'objet, enfin c'est nettement moins évident en deux mots)
 
L'openGL, c'est simplement un automate complexe, et il est possible de faire beaucoup de choses intéressantes quand on sait se servir du Z-buffer, du stencil buffer, et des différentes conditions. Par exemple, une vue en coupe automatique...
 

Ben s'il désactive le Z-buffer, elles sont toutes affichées dans l'ordre où le programme les fournit. Ca dépend de ce qu'il voulait faire, mais à part le fait qu'on voit parfois les particules de derrière devant d'autres particules plus proche, ça marche. Et si les particules utilisent de l'alpha, ça ne peut que marcher... (enfin bon, ça dépend de ce que tu veux faire)

Si tu veux un fond d'écran, tu as mon code plus haut. Si tu veux un quad texturé, pas à pas :
 
* à l'initialisation :
 
- tu définis un entier qui contiendra ton numéro de texture

 
- tu demandes à la carte vidéo d'attribuer un numéro pour ta texture :

(se lit comme la demande à la carte vidéo "fais-moi de la place pour 1 texture, et stocke-moi son numéro dans la variable textureID" )
 
- tu charges la texture en mémoire (avec GLaux, par exemple, mais tu peux aussi écrire ton propre logiciel de lecture, ou en utiliser un existant... le tout est d'avoir un buffer qui contient l'image)

l'image est chargée, et tu peux accéder au buffer avec image->data
 
- tu dis à la carte vidéo que tu vas faire des choses avec la texture que tu lui a demandé plus tôt :

A noter qu'on lui fournit le type de texture (image 2D) parce qu'il va réserver de la place dans la mémoire vidéo, et donc il lui faut savoir combien de place il va falloir... A présent, toutes les commandes liées aux textures utiliseront la texture qui nous intéresse
 
- tu lui précises comment elle doit la modifier si elle est trop petite/grande :

LINEAR, ce sera moins moche... au besoin, c'est là qu'on définit des MIPMAPs pour éviter les scintillements quand la texture est très petite. Il y a aussi d'autres paramètres pour la façon dont la texture se comporte quand on sort de la zone (bouclage, inversion, etc.)
 
- puis tu mets l'image dans la mémoire vidéo :

0 est là pour le niveau de détail des MIPMAPs, à laisser (de toute façon, les MIPMAPs sont bien générés automatiquement au besoin). 3, c'est le nombre de couleur à utiliser en INTERNE dans la carte (pas forcément celui de l'image). Suit la taille de l'image, le 0 ensuite correspond à la taille de la bordure (ie pas de bordure), on précise que l'image est en RGB, que les données du buffer sont des entiers 8bits non signés, et on fournit le pointeur vers les données de l'image.
 
- Facultatif, je crois qu'on peut libérer la mémoire centrale en virant l'image à présent inutile :

(à vérifier, mais j'en suis sûr, c'est juste pour ne pas dire de bêtises)
 
Et c'est fini pour l'initialisation, la texture est en mémoire !
 
 
* à l'exécution:  
- chaque fois que tu as besoin de la texture, il faut dire que c'est celle-là que tu vas utiliser. Donc donner à la carte vidéo son numéro interne, textureID !

 
- puis, dessiner le polygone

 
 
Si un point est obscur, dis-le...
 
 

Rah, Sobel... ça me rappelle de bons souvenirs de Master 2...

Il ne faut pas, si ça peut te rassurer, en général je merde pas mal moi-même
 
Il faut prendre les choses très calmement et une à une. La première chose, c'est d'avoir un truc à l'écran, quel qu'il soit. Trop souvent, l'écran est noir parce qu'il y a une caméra à l'envers ou quelque chose de ce genre. Une fois que tu as repéré la scène, on peut chercher à comprendre ce qui cloche.
 
Tu as mis quoi dans camx-camz, centerx-centerz et hautx-hautz ?
 
Si tu ne vois rien, le mieux c'est de procéder ainsi : faire une fonction Repaint à part et qu'on remplit au fur et à mesure (en rajoutant la couleur, la texture, mais une chose à la fois). Il faut :
- placer la caméra
- afficher n'importe quoi et le voir
 

Quand la lumière est activée, tu ne devrais utiliser que du blanc comme couleur, les objets utilisent la couleur définie dans les glMaterial (qui définissent comment un objet renvoie la lumière, donc de quelle couleur il apparait). Ca n'a pas de sens de définir une couleur, puisque si la lumière est rouge, un objet bleu doit apparaître violet.
 
Je te recommande VIVEMENT de ne PAS utiliser la lumière avant que tout ne fonctionne. Et d'au moins toujours laisser un objet (si possible une boite autour de la scène) qui est tracé avec le GL_LIGHTING désactivé, tant que le programme n'est pas fini.

Vous m'avez donné l'envie de m'y remettre  
 
Autrement, je souhaiterai pouvoir concevoir des modèles complexes par un log de 3D. Lequel s'en sort bien pour une exportation vers OpenGl ?