Probleme avec le rouge ... [resolu] [OpenGL] - Divers - Programmation
Marsh Posté le 04-01-2005 à 11:44:00
T'as pas un problème dans le morceau "reverse all of the colors. (bgr -> rgb)" ?
Marsh Posté le 04-01-2005 à 11:46:54
Non je crois pas, je mets en commentaire cette boucle for et c'est toujours pareil ...
Marsh Posté le 04-01-2005 à 11:54:10
Et le pire c'est que ca "assombri" toute la scene, tous mes objets "coloriés" donc non texturés deviennent sombres, j'ai testé plusieurs textures ca vient pas d ela texture elle meme, j'ai l'impression que le rouge "infecte" les couleurs dans le buffer general enfin je sais pas comment le dire autrement
Marsh Posté le 04-01-2005 à 12:28:03
Bon j'ai trouvé dans "OpenGL Super Bible" la fonction glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL); et comme par magie ca m'affiche bien les couleurs reeles des textures mais ca fausse completement les couleurs des objets que j'avais colorié à la main (avec glColor3f)
Code :
|
En gros ... je comprends rien mais c'est pas grave
Marsh Posté le 04-01-2005 à 12:33:50
tu ne te serais pas planté dans le "saut" de l'entête car en regardant le format bmp (j'ai trouvé ça sur google j'espère qu'il n'est pas faux !) http://www.fortunecity.com/skyscra [...] ffrmt.html j'ai l'impression que l'entête est plus grande que 25 octets donc décalage donc pb de couleurs... en plus il semblerait que les pixels fassent 4 octets et non pas trois...
Marsh Posté le 04-01-2005 à 12:35:35
C'est ce que je me disais. Grosse probleme dans la routine de lecture de l'image, quand il inverse les couleurs...
Marsh Posté le 04-01-2005 à 12:37:28
Bah il est clair que le bitmap est un peu plus compliqué qu'une série de pixels de 3 octets (bgr) !
Marsh Posté le 04-01-2005 à 12:40:06
j'ai trouvé le format sur microsoft à l'adresse http://msdn.microsoft.com/library/ [...] s_5jhv.asp faudrait comparer avec ce que tu as fait (taille de l'entête, etc...)
Marsh Posté le 04-01-2005 à 12:58:33
C'est cool merci pour le lien
A mon avis ca vient du fait que je fait tout ca sous cygwin et que les bmp proviennent du Paint de windows ... et je doute que les 2 ont le meme type de headers.
Marsh Posté le 04-01-2005 à 13:00:31
le binaire restant le même cygwin/paint même combat... je pense qu'il faut mieux s'orienter vers des fonctions standards (cf le post de bjone)
Marsh Posté le 04-01-2005 à 13:03:54
bjone a écrit : heuuuu le GLUT as pas de loader de BMP/TGA & co ? |
Ca ce serai d'enfer ! mais à mon avis c'est mort ce serait trop beau pour etre vrai, sachant que glut a été abandoné depuis 1997 je crois.
Marsh Posté le 04-01-2005 à 16:21:36
J'ai un autre gros probleme, des que je charge plusieurs textures dans mon tableau de textures et je selectionne la texture voulue avec glBindTexture(GL_TEXTURE_2D, texture[type]) ou le type est un int ... j'obtiens toujours la meme texture partout cad la derniere de mon tableau de textures. Je pige pas
Code :
|
Marsh Posté le 04-01-2005 à 18:27:42
bah faudrait pas donner un autre numéro à la texture ? ou alors j'ai pas compris ce que faisait glBindTexture
Marsh Posté le 04-01-2005 à 18:33:02
Elle permet de choisir quelle texture on veux appliquer glTexCoord ...
Code :
|
Marsh Posté le 04-01-2005 à 18:34:18
donc faudrait peut-être que les différent texture[i] est des valeurs différentes (genre 1,2,3, ...)
Marsh Posté le 04-01-2005 à 18:42:51
C'est vrai mais meme quand il m'affiche une texture partout toutes les valeurs de texture[i] valent 0 ??!!??
Marsh Posté le 04-01-2005 à 18:45:50
bah pour moi c'est normal, tu charges toutes les textures avec comme numéro 0 donc à chaque fois tu écrase texture précédemment chargée : il ne reste que la dernière...
Marsh Posté le 04-01-2005 à 18:52:46
Ah j'ai trouvé, j'ai oublié l'instruction glGenTextures() qui les crée ... et voila un oubli cherement payé !
Marsh Posté le 04-01-2005 à 18:53:22
Merci dreameddeath
Marsh Posté le 04-01-2005 à 18:56:24
bah je t'ai pas beaucoup aidé (juste des idées en l'air). mais bon sans avoir jamais fait d'openGL...
Marsh Posté le 04-01-2005 à 19:08:29
Je sais pas si t'as corrigé, mais les noms (identifiants) des textures sont des unsigned int.
Marsh Posté le 04-01-2005 à 19:28:45
Tu veux dire changer int texture[5] en GLuint ... si c'est ca j'ai testé et ca change rien au niveau de "l'infection" du buffer general par le rouge (dans le cas ou j'applique pas la fonction glTexEnvi).
Marsh Posté le 04-01-2005 à 19:32:42
mets des snapshots de ton problème sur http://www.imageshack.us/
Marsh Posté le 04-01-2005 à 20:00:04
Voilà
Avec glTexEnvi(... GL_BLEND)
http://img140.exs.cx/my.php?loc=im [...] end4qy.jpg
Avec glTexEnvi(... GL_DECAL) => la c'est nikel ... mais il y a un beug kamem
http://img140.exs.cx/my.php?loc=im [...] cal4me.jpg
Sans glTexEnvi
http://img140.exs.cx/my.php?loc=im [...] cal1lx.jpg
Le beug, comme je l'ai dit plus haut reside dans le fait que les choses que je colorie a la main avec glColor prenent tous la couleur du bord de la premiere texture (celle dans texture[0]) j'ai fait des tests et si je mets du rose le cadre et la balle deviennent roses etc ...
Marsh Posté le 04-01-2005 à 20:13:51
En fait je me suis trompé, c'est la couleur des bords de la derniere texture qui est extrapolé et non de la premiere ...
Enfin une image est plus parlante :
http://img140.exs.cx/my.php?loc=im [...] eug8un.jpg
Marsh Posté le 04-01-2005 à 23:43:24
Bon alors on va reprendre tranquillement quelques bases.
Premierement oui je parlais bien de ton int texture[1]; qu'il faut changer en GLuint texture[1];. Si tu regardes le prototype de glGenTextures, tu verras que le 2e parametre attendu est bien un GLuint*. Donc en lui filant un int*, tu as un cast implicite avec surement un warning du compilo. "Ca change rien" mais fournir des parametres avec le bon type, c'est quand meme la base.
Ensuite, parlons du texturage. Il faut bien avoir a l'esprit qu'OpenGL est une "state machine". Quand tu modifie l'état, tout ce qui suit est affecté par ce changement. Si tu veux texturer certains objets, tu utilises glEnable(GL_TEXTURE_2D), tu envoies tes primitives avec les coordonnées de textures, et voila! Sauf que pour les objets non texturés qui suivent, faut pas oublier de faire le glDisable(GL_TEXTURE_2D). Sinon, meme si tu ne fournis pas de coordonnées de texture, OpenGL va utiliser les dernieres coordonnées connues, et ce pour toutes les vertices qui suivent. Il va donc fetcher le dernier texel désigné et l'utiliser pour le calcul des fragments.
Autre chose que tu n'as pas l'air d'avoir assimilé : au niveau des textures, il y a deux choses qui entrent en ligne de compte dans leur utilisation.
- D'un coté les propriétés de chaque texture, que tu définis par glTexParameter. A chaque glTexParameter tu modifies le parametre de la texture courante (la derniere bindée). Ces parametres sont persistants et font partie de l'état attaché à la texture. A chaque fois que tu binderas la texture, les parametres ainsi définis seront utilisés.
- De l'autre coté, il y a l'état de l'unité de texturage. C'est ce que modifie glTexEnv. La il s'agit de définir comment on va combiner plusieurs couleurs qui arrivent simultanément pour calculer la couleur finale du fragment. Les couleurs qu'il faut combiner sont d'une part la couleur courante (attribuée par glColor ou calculée par le module d'éclairage) et d'autre part la couleur du texel correspondant aux coordonnées de textures. J'insiste sur le fait qu'il y a toujours une couleur courante, meme si tu n'en as pas spécifié explicitement.
Bon alors comment on mélange les couleurs? C'est ce que décide GL_TEXTURE_ENV_MODE. Par défaut (il y a toujours des valeurs par défaut, ce qu'on appelle aussi l'état initial de la machine ), c'est GL_MODULATE. Ce mode multiplie la couleur courante avec le texel. Petite parenthse : comme on multiplie des valeurs (les intensités lumineuses des différentes couches) entre 0.0f et 1.0f (peu importe le type, ça revient au meme), le résultat est toujours inférieur au plus grand des deux, donc on "assombrit" la scene - fin de la parenthese. Comme c'est pas ce qui t'intéresse, il faut donc effectivement que tu utilises explicitement glTexEnv pour changer ce mode. GL_DECAL ou GL_REPLACE devraient faire l'affaire dans ton cas. GL_BLEND pas trop, ça fait intervenir la couleur associée à l'unité de texture. Je rappelle que ce mode est une propriété associée à l'unité de texture (courante dans le contexte du multi-texturing, sinon il n'y en a qu'une). Si tu as plusieurs types d'objets dont certains sont texturés avec GL_DECAL et d'autres avec GL_MODULATE, il faudra faire le changement adéquat à chaque fois (le bind de la texture ne suffit pas).
Bon alors quand t'auras bien digéré tout ça, tu comprendras mieux ce qui se passe
Marsh Posté le 05-01-2005 à 00:00:31
Merci pour ce cours d'openGL pour les nuls , ça a le mérite de mettre les choses au clair.
Marsh Posté le 05-01-2005 à 00:25:39
C'est super sympa merci J'y vois un peu plus clair maintenant, ca va marcher de feu de dieu
Marsh Posté le 09-01-2005 à 19:02:25
Petit UP !
Voila si vous avez un peu de temps et que vous voulez tester un ptit casse-brique Ya quelques ptits bugs mais sinon c'est du bon !
Voici le lien : http://corbieres.unice.fr/~bodnart [...] public.zip
C'est pour windows pour l'instant.
Le code source sera dispo lundi soir, dans le meme fichier.
EDIT : Demandez le moi plutot ... comme ca au moins je saurais si ca interesse qq'un
Marsh Posté le 12-01-2005 à 23:15:38
héhé ça m'a rappelé mes bons vieux souvenirs d'arkanoid sur CPC
Ca fait bizarre de jouer à la souris mais bon, on s'y fait. C'est un peu trop facile à mon avis. Je me rappelle que au clavier sur le CPC, il fallait un certain temps pour aller de gauche a droite (et donc fallait essayer d'anticiper). La avec un grand coup de souris c'est "instantané".
Bon sinon pour les choses qui fachent :
- je suis tombé sur un bug ou la balle restait collée contre le mur et ne faisait que monter et descendre (screenshot).
- en quittant (touche esc), j'ai vu furtivement un crash dans la console, chose confirmée par padbal.exe.stackdump (access violation)
- cygwin1.dll 1.08Mo
- la balle unicolore est pas super sexy comparée au reste qui est texturé
[apres deuxieme essai]
- ça plante si on perd la balle normale et qu'on a encore la balle bonus (pas de réponse)
Marsh Posté le 13-01-2005 à 00:32:44
Merci de l'avoir testé, c'est cool
Pour le bug de la balle qui reste collé c'est un probleme de gestion de collision, je me suis battu toute une soirée sans resultat et j'ai laissé tomber en pensant que ca arriverai assez rarement (bein non en fait) mais ce devrait pouvoir se regler ...
Pour la creation du fichier padbal.exe.stackdump, c'est assez bizzare en effet ... il apparait a chaque fois apres le lancement.
Pour la taille de cygwin1.dll je suis d'accord elle est un peu démesurée Je ne sais pas éditer les .dll encore il y a peut etre plein de choses inutiles a virer ...
Pour la texture de la balle c'est sur c'est pas top, faut que je trouve un tuto sur les placages de textures sur des objets non-carrés Ce seras reglé !
Pour le bug de la balle normale si la bonus y est encore ce sera reglé le plus vite possible aussi !
Je pense rajouter un truc du style apres le troisieme niveau la barre se retrecit tous les 2 niveau ....
Merci pour les commentaires en tout cas
Marsh Posté le 04-01-2005 à 11:32:23
Voila j'ai un probleme dés que j'autorise la fonction LoadGLTextures() a etre executé dans InitGL() la couleur blanche est remplacée par la couleur rouge et ceci non seulement au endroits texturé mais dans toute la scene, y'a t'il un moyen de "reguler" les rvb de toute la scene ???
Message édité par Chronoklazm le 09-01-2005 à 19:26:37