GranDFrère

Salut à tous. C'est plutôt très bon pour le LIGHTING ( éclairage ), j'ai pratiquement terminé, mais il me reste quelques points techniques à 'éclaircir'. J'ai fait de la lumière ponctuelle, de la lumière atténuée avec une distance et un angle, et de la lumière spéculaire, le tout sur un cube. Plus ça avance, plus les doutes s'estompent. Et c'est très important. La texture approche .... Bon week-end à tous.

Salut à tous. Désolé les gars, mais je ne suis pas encore dans les librairie VI (vidéo). Mais vu le peu de temps consacré en explication dans la doc, j'ai l'impression que ce ne doit pas être compliqué. Du moins comparé au reste. A+ et bon samedi

Salut à tous. C'est bon pour les matrices indexèes, ça marche impécable, et donc je maitrise mieux le sujet. En effet, j'ai pu démontrer que cette méthode était utile pour n'affecter que certains vertices et pas les autres. Pour l'instant je fini une petite démo sur les matrices indexées, puis je reviendrai sur le 'Lighting'. Bonne journée à tous.

Salut à tous. Ca y est, j'ai trouvé mon erreur. Le problème de la matrice ixdexée est terminé. Voici ce que c'était: au lieu d'écrire ceci pour déclarer le pointeur de la matrice GXSetArray(GX_POS_MTX_ARRAY, matrice_indexee, 3*4*sizeof(f32)); , j'avais écrit ceci GXSetArray(GX_VA_PNMTXIDX, matrice_indexee, 3*4*sizeof(f32)); . L'argument GX_VA_PNMTXIDX n'est pas bon pour GXSetArray, il faut GX_POS_MTX_ARRAY. GX_VA_PNMTXIDX c'est pour le descripteur GXSetVtxDesc. Sinon tout va bien, et la programmation continue. Bon jeudi. ^_^

Salut à tous. Et non, je n'ai toujours pas trouvé la solution à mon problème. Passez tous un bon week-end.

Je sais pourquoi Totol, tu arrives à afficher quelque chose. 1) Je dis quelque chose , mais je crois que c'est un carré donc une face du cube. 2) Il faut savoir que lorque l'on utilise DEMOInit et donc GXInit, la matrice courante mise par defaut par GXSetCurrentMtx est GX_PNMTX0. Tu utilises GXLoadPosMtxImm(mv, GX_PNMTX0); pour charger ta matrice model de vue 'mv' dans l'emplacement 'mémoire matrice' GX_PNMTX0. Sachant que cette 'mv' provient de MTXLookAt et est donc la caméra. Donc effectivement quelque chose s'affichera, car GX prend ce qu'il y a dans la matrice courante. 3) Dans GXLoadPosMtxImm Imm signifi Immediat et non pas Index, contrairement à GXLoadPosMtxIndx où Indx veut dire Index. 4) Le cube ne tourne pas si je me souviens bien. Donc la matrice indexée n'affecte pas les vertex (ou vertices). 5) Si ça affiche un carré c'est à cause de GXSetArray(GX_VA_POS, points_cube, 3*sizeof(f32)); point_cube étant le pointeur du tableau contenant les coordonnées des 8 points du cube. 6) on n'en reparle ce soir. Je te remercie. 7) Je peux me tromper, ce qui signifirait que je n'ai rien compri. 8) A+ 9) Un paquet de pâtes et 3 poireaux.

Bonjour à tous. Alors là les gars et les filles, je suis totalement bloqué sur les matrices indexées. J'ai beau lire la Doc GX et MTX, je ne vois pas où pourrait être mon ou mes erreurs. Le compilateur ne décelle aucune erreur. Mais pourtant rien ne s'affiche. Ma matrice est rangée dans un tableau (Array) comme suit: f32 matrice_indexee[3][4]; C'est une matrice 3x4. f32 est du type float. Elle contiendra des données issues d'une matrice de rotation. Donc dans le tableau matrice_indexee il y aura un matrice (3x4). Le principe est simple, la matrice qui sera dans matrice_indexee sera charger dans dans un emplacement mémoire qui s'appelle 'mémoire matrice'. Voici les fonctions que j'utilise pour utiliser une matrice indexée: (GP = Graphic Processor) - Ici je déclare au GP que je vais utiliser une matrice indexée: GXSetVtxDesc(GX_VA_PNMTXIDX,GX_INDEX8); - Ici j'indique au GP un pointeur et un écart (stride) de 48 octets: GXSetArray(GX_VA_PNMTXIDX, matrice_indexee, 3*4*sizeof(f32)); pointeur: matrice_indexee (le tableau où sera stockée la matrice) stride= 3x4x4 = 48 car c'est une matrice de 3x4 et sizeof(f32)= 4 octets Ca dit au GP où est le tableau matrice_indexee. - La matrice qui sera dans le tableau matrice_indexee sera elle chargée dans la 'mémoire matrice', ceci pour plus de performance. Car la transmission de données indexées est plus rapide puisqu'elles ne passent pas par le 'Gather buffer'et 'la Graphic FIFO' contrairement à la transmission Directe. Voici la fonction de chargement : GXLoadPosMtxIndx(0, GX_PNMTX0); On charge le contenu de matrice_indexee, qui est en DRAM, à partir de l'index 0 dans l'emplacement GX_PNMTX0 de la 'mémoire matrice'. Si j'avais une deuxième matrice dans le tableau et que je voulais charger celle-ci, l'index serait 1 que je pourrait très bien mettre dans l'emplacement GX_PNMTX0 . Il existe 10 emplacements qui vont de GX_PNMTX0 à GX_PNMTX09. - Le contenu du tableau matrice_indexee évoluera (donc modification de données) en utilisant la cache CPU. Le chargement de ce contenu (qui est une matrice je le rappelle), qui est en DRAM, vers la 'mémoire matrice' passe par la cache Vertex. Il y aura donc ici une "Incohérence de données" puisqu'il n'y a pas de liaison entre cache CPU et cache Vertex. Il faut vider la cache CPU. Il faut donc utiliser cette fontcion: DCStoreRange(&matrice_indexee, 48); matrice_indexee contien 48 octets. Mais attention, il y a une règle. Il faudra appeler cette fonction avant que le GP charge la matrice, donc avant GXLoadPosMtxIndx(0, GX_PNMTX0); - Dernière fonction. Ici on transmet la matrice qui est dans l'emplacement GX_PNMTX0. Cette fonction est entre GXBegin et GXEnd. GXMatrixIndex1x8(0); 0 est l'indexe de GX_PNMTX0, l'emplacement où est stocké la matrice. 1 sera l'indexe de GX_PNMTX1 ,etc ... La fonction est placée suivant un ordre bien precis, par exemple: GXMatrixIndex1x8(0); GXPosition1x8(point); GXColor1x8(couleur); Voilà fini pour les fonctions. L'interet d'une matrice indexée est qu'elle n'affectera que les vertex que lui désignera avec GXPosition1x8(point); , et pas les autres vertex de l'espace 3D. C'est en tout cas ce que j'ai compris, et il ma fallu 3 semaines pour en arriver à un résultat négatif. Aussi je vous implore de bien vouloir m'aider. (je ne vais pas non plus me suicider pour ça) Merci et bonne semaine à tous.

Salut yoyo, nous réfléchissons à ta proposition que je trouve sympat. A+

bonne soirée tout le monde. Avant tout je tiens à vous dire que DomCaz et GranDFrère sont la même personne. Ceci pour enlever toute ambiguïté. DomCaz, c'est mon nom de programmeur. Cela étant, maintenant que nous progressons, je vais étudier l'éclairage (lighting) et les matrices de transformation indexées. Je vous en reparlerai plustard quand je connaîtrai mieux le sujet. Bon appétit à tous.

bon dimanche les amis. Avec toutes ces émotions de ce wekk-end (anniversaire de ma femme et cette news dans Gueux), nous avons oublié de remercier Legeux et toute l'équipe de ce site. Vraiment cela nous a fait un immense plaisir. MERCI On vous aime ....

Goooooooooooold, comment vas-tu ? Merci ça nous touche beaucoup, Car SDK ou non , il faut du travail pour en arrivé là. Décidément pipomolo42 tu es incorrigible. Mais je ne t'en veut pas et te comprend. Attention, chaud devant .... On arrive.

Bonjour à tous. Je vous avais promis que le groupe vous donnerait un 'DOL' qui montreraitl'état de notre avancée, nos compétences actuelles. Elles ne sont pourl'instant que technique. Ne voyez rien d'artistique, car il nous fallait dans l'immédiat nous familiariser avec la Gamecube. Et il nous reste encore, un long chemin à parcourir. Mais, ce ne sera non pas un, mais cinq 'DOL' que vous pourrez regarder ce week-end. Ces programmes affichent des cubes (non texturés) en rotation, à l'aide de techniques différentes. Et à l'heure actuelle, nous en recherchons d'autres.Ces programmes peuvent être considérés comme des démonstrations de manipulation de vertex qui en groupe de huit forment un cube. Sachez qu'un vertex est un point dans l'espace auquel sont rattachés des attributs. Ces attributs sont au nombre de huit: - La position - La normale - La couleur 0 - La couleur 1 - Les coordonnées de texture - Une matrice indexée de position/normale - Une matrice indexée de texture Il faut au moins les attributs position et couleur pour afficher un point à l'écran. Chaque attribut doit recevoir et transmettre au GP (Graphic Processor) des données. Ces données seront transmisent au GP de deux manières: - En direct, c'est à dire que l'on donne directement les données. Elles passent par la cache CPU. - En indexé, c'est à dire que les données sont stockées dans des tableaux. Elles passent par la cache VERTEX. Les données qui passeront par la cache VERTEX seront transmisent plus rapidement que par la cache CPU, car le chemin d'accès aux données est différent. Nous avons exploité ces deux méthodes, mais ici les cinq programmes exploitent uniquement de l'indexé. De plus, pour que les vertex puissent se mouvoir dans l'espace, donc modifier les positions, nous devons manipuler des 'caméras', des matrices de transformations et de projections, et même des vecteurs. Ces différentes technique sont ici utilisées. Voici donc les 'DOL' et leur liens : - Dark Side Of the Cube. ---------------------- Ici nous utilisons une caméra qui est fixe et trois matrices de rotation (axe x,axe y,axe z) font tourner l'espace 3D et le cube tourne. Vous remarquerez aussi qu'une face (face arrière) reste cachée. Elle vous sera dévoilée plustard. + lien + http://kgstcj.share.free.fr/Dark_Side_of_the_Cube.dol - Carre bouge avec la manette 1 et la camera avec la manette 2. ------------------------------------------------------------- Ormis le fait que le nom soit long, ce programme est intéressant car il utilise deux caméras, rendant ainsi indépendants deux cubes. De plus vous pouvez utiliser deux manettes. Ici il y a trois matrices de rotation (axe x,axe y,axe z) pour une caméra (manette 2) et trois matrices de rotation pour un cube (manette1). les boutons: manette 1 : X Y et Z manette 2 : X Y et Z + lien + http://kgstcj.share.free.fr/Carre_bouge_av...a_manette_2.dol - Cubes Planètaires. ----------------- c'est avec ce programme que nous avons réussi , pour la première fois, à mouvoir plusieurs cubes (au nombre de 3) avec une seul caméra. Il utilise trois matrices de rotation (axe x,axe y,axe z) et nous traitons des vecteurs. On utilise ici le Flushing Cache qui est nécessaire lors de l'utilisation de tableaux. + lien + http://kgstcj.share.free.fr/Cube_Planetaire.dol - A Chacun son Axe. ---------------------- Dans ce programme, sont exploitée trois caméras qui ainsi crées trois repères indépendants. Donc chaque cube peut tourné sur un axe (ou plusieur) différent de celui des deux autres cubes. + lien + http://kgstcj.share.free.fr/A_chacun_son_Axe.dol - 4 Cubes ....... ---------------- Vous vouliez du cube, alors en voici 4. Les quatres démonstrations précédentes utilisaient comme axes de rotation ceux du repère de l'espace 3D. Là les quatres cubes utilisent chacun un axe de rotation parallèle à un axe du repère de l'espace 3D, soit x ,y ou z. C'est le programme le plus abouti. Les boutons : A ----> Rotation de la caméra autour de l'axe y dans le sens indirect. B ----> Rotation de la caméra autour de l'axe y dans le sens direct. Haut -----> Sélectionne le cube du haut. Bas -------> Sélectionne le cube du bas. Gauche ---> Sélectionne le cube de gauche. Droite ----> Sélectionne le cube de droite. X : Fait tourner le cube sélectionner par rapport a un axe parallèle a l'axe X et passant par le centre du cube sélectionné. Y : Fait tourner le cube sélectionner par rapport a un axe parallèle a l'axe Y et passant par le centre du cube sélectionné. Z : Fait tourner le cube sélectionner par rapport a un axe parallèle a l'axe Z et passant par le centre du cube sélectionné. + lien + http://kgstcj.share.free.fr/4_Cube_Dans_To...ment_camera.dol Ces programmes ont été confectionnés par 3 coders : **** Kirua ----- Torner ------ DomCaz **** Sachez tout de même qu'il y a à peine 3 mois nous ne nous connaissions pas, que l'on ne savaient pas que l'on programmerait sur la FABULEUSE Gamecube. Alors vous aussi essayez, ça vaut la peine de voir le coeur de notre Gamecube battre. Les membres du groupes, sont tous plombiers (comme Mario): CODERS : Torner, Kirua, DomCaz GRAFIX : X-CM MUZIX : MisterJbam DOCX : Contre-courant Et bien voilà, passez un bon week-end, gros bisous aux filles, et bonne anniversaire à ma femme adorée. (DomCaz = GranDFrère) (ToToL = Kirua)

Merci nostro. on peut toujours discuter sur msn tu sais.

Bon samedi à tous. Ca y est, c'est bon ça marche avec les tableaux. Grace à DCStoreRange. GXInvalidateVtxCache n'est pas utile pour l'instant. Mon cube tourne, sans l'aide de la caméra qui est fixe. Bonne soirée.

salut à tous. Je pense avoir trouver les raisons qui font que mon problème de tableaux perciste. Voyez plutôt ( qui au passage est le chien de Mikey) ... DATA COHERENCY -- CONCORDANCE DES DONNEES Par concordance, il faut comprendre une liaison, une connexion des données avec leur environnement. Et l'environnent le plus proche des données c'est bien la mémoire. Ici, c'est justement un déficite de concordance entre les mémoires caches du CPU et celles du GP qui font defauts. La mémoire centrale c'est la DRAM. La Game Cube comporte plusieurs parties du processeur (gekko) et du hardware (Flipper...) qui peuvent mettre à jourla mémoire centrale, ne serait-ce que pour de simples accés écriture/lecture. A eux deux,le CPU et le GP (Graphic Processor) contiennent une variété de caches pour les données. Comme le hardware ne peut pas maintenir une concordance (une connexion) des données dans la mémoire centrale et dans les différentes caches associeés, il y a trois sources de problème de concordance possibles: 1) - Quand le CPU modifie ou génère des données destinées au GP. 2) - Quand le CPU écrit des données à travers son 'write-gather buffer' vers la mémoire centrale. 3) - En chargeant de nouvelles données, destinées au GP, issues du DVD dans la mémoire centrale. En d'autre termes, si vous utilsez des données, issues de la cache CPU, du write-gather buffer ou du DVD,destinées à l'une des caches GP (cache vertex ou cache texture) vous pouvez avoir l'un de ces problèmes. C'est le problème du DATA COHERENCY. D'abord ce problème est dû à une volonté de simplifier la conception du hardware. Mais il peut être résolu grace à des fonctions. Je rappelle que mon objectif est d'afficher un cube à l'écran,donc des points. Une chose qu'il faut savoir avant de continuer, c'est que pour afficher un point à l'écran on utilise un 'vertex' .Un vertex est un point dans l'espace auquel est rattaché un groupe d'attributs. Ces attributs sont la position, la couleur, la texture et la normale. On peut transmettre des données à ces attributs commes les coordonnées x,y et z pour la position. Ces données sont transmisent de deux manières: En direct ou en index. Moi j'utilise des données indexées et non pas direct car je vais exploiter des tableaux qui contiendront mes données. En direct on donne directement les données. En index on utilise des tableaux ( Arrays ) qui stockent les données. ILLUSTRATION Mon problème est le suivant: Je vais utiliser 3 tableaux: vecteurs_source, vecteurs_destination et points_cube. Vecteur_sources est rempli et les 2 autres sont vides. Ces 3 tableaux sont stockés dans la mémoire centrale. Le tableau points_cube contiendra des valeurs destinées au GP et, pour des raisons de performance, vont être stockées dans la cache vertex du GP. C'est un choix que j'ai fait. Pour l'instant il n'y a rien dans ce tableau donc le GP n'affiche rien. Le GP attend des points à afficher, et ces point sont appelés vertex ( mais en anglais c'est vertices au pluriel et vertex au sigulier, tout comme index au sigulier et indices au pluriel). J'ai un tableau (vecteur_sources) de valeurs qui sont sous forme de vecteurs. Je vais faire le produit de ces vecteurs par une matrice de rotation, et le resultat sera ranger dans un autre tableau (vecteurs_destination) et les valeurs de ce tableau seront aussi des vecteurs. Ensuite les valeurs du tableau vecteurs_destination (qui sont des vecteurs) je les converti en points pour les ranger dans le tableau points_cube. En effet, le GP attend des points. Toutes ces modifications de valeurs (donc de données) c'est le CPU qui les a effectué. Donc le CPU a modifié le tableau points_cube, certe en y rangant des valeurs, mais aussi en les générant. C'est le 'problème 1' qui s'applique dans ce cas. Donc le GP ne tiendra pas compte des ces valeurs, car elle seront issues de la cache CPU. Finalement, si le CPU génère ou modifie des données graphiques à travers sa cache, les mémoires du type: mémoire centrale ou cache vertex et texture, contiendront des données éculées, usée, bref incorrectes. Alors pour envoyer des données correctes au GP, il faut Vider la cache CPU de ses données et invalider la cache vertex ou texture du GP. De plus ce qu'il faut savoir, c'est que le CPU manipule les données une trame (image, frame) en avance sur le GP, aussi il y a une technique performante pour maintenir la concordance des données: - Grouper toutes les données graphiques modifiées par le CPU dans la mémoire centrale séquenciellement , pour vider efficacement les données de la cache CPU. - Invalider le cache vertex ou texture au début de chaque trame. ( Vider la mémoire cache du CPU c'est le Flushing Cache. To flush the cache.) Les fonctions pour le flushing cache suivant leurs utilisations sont: DCFlushRange, DCStoreRange et DCInvalidateRange. La fonction pour invalider la cache vertex est: GXInvalidateVtxCache. Je n'ai pas encore essayé cette méthode. Mais la question que je me pose est: Mais où ce vide la cache du CPU? Réponse: Je pense que ce sera dans la mémoire centrale grace à DCStoreRange. Plus de 2 semaines de recherche pour en arriver à cette conclusion. Bon ween-end à tous.

Salut à tous. Aujoud'hui, j'ai besoin de ceux que seraient calés en programmation sur la GC. En effet je suis bloqué et à bout d'idée. Voilà, lorsque que je veux écrire ou modifier une valeur dans un tableau (que ce soit en 'local' ou en 'global') comme par exemple: float points_cube[24]; points_cube[0]=-100.0; points_cube[1]=-100.0; . . . points_cube[23]=100.0; A l'emplacement [0] du tableau il n'y aura pas la valeur -100.0, au [1] il n'y aura pas non plus -100, etc ... Il n' y aura jamais la valeur que je souhaiterai. Sous windows ça marche mais sous GC non. Pourquoi? Si je ne peux pas manipuler les tableaux, je n'irai pas loin. Merci àvous tous. Et bonne soirée.

Merci à tous ceux qui nous encourage. Merci à Gold et Legueux. Le premier .DOL que je vous donnerai approche de jour en jour. Mais se sera juste un aspet technique, de base, de nos compétences actuelles. Il n'aura rien d'artistique. Le plaisir de voir une superbe démo vous l'aurez. Donner une date serait prématuré. Bon week end à tous.

Salut à tous. Bon, ça y est. J'ai réussi à afficher un cube en 3D observer par une caméra. Bon le cube ne tourne pas et ne se translate pas, mais il saurait tarder. Pour l'affichage je passe par des vertices ( vertex au singulier et vertices au pluriel) et la caméra est gérée par une matrice. On peut à l'aide de la caméra touner autour du cube. Mais il faut aussi savoir animer un objet sans la caméra. La caméra n'est là que pour observer . Donc le groupe progresse et c'est tant mieux. A plus tout le monde.

Salut à tous. Je me sent pas encore pret à donner un Dol. Il faut que ce soit intéressant à montrer. Pour l'instant ça ne casse pas des briques. Mais c'est promis que je vous filerai un dol. Bonne journée à tous.

Merci pour vos suggestions. Gold Cube Team c'est pas mal du tout. Mais je ne suis pas le seul décideur. Cà y nous avons affiché un triangle avec la GC. Mais il faut mieux maitriser le sujet. Des questions reste en suspend. Bonne soirée.

Salut à tous ça fait 2 semaines que j'ai fini mon apprentissage au C. J'ai décidé de m'attaquer à la programmation. Objectif: Afficher un triangle et l'animer. Dans un premier temps je ne pense pas le texturer. Il va falloir connaître tout ce qui est vertex, matrices et vidéo interface pour l'affichage. Ca a l'air compliqué, mais je m'accroche. Il faut dire que la doc est en anglais. Jai commencé par la Graphic Librarie ( GX) et je verrai au fur et à mesure ce qui gravite autour, c'est à dire les matrices (MTX) et la vidéo interface (VI). Nous n'avons toujour pas de nom pour notre groupe. Je vous souhaite une bonne semaine.

Salut à tous. Merci beaucoup les gars, cela fait plaisir à lire. J'ai hate d'en finir avec l'apprentissage du C, pour vraiment programmer. Mais il faut savoir, parfois, ne pas brûler les étapes. La patience paiera. Sinon il est vrai que le groupe n'a toujours pas de nom. Ce n'est pas notre priorité. Bonne nuit à toute la communauté. :lol:

Salut à tous. Cela fait quelques semaines que je ne suis pas venu consulter ce topic. Me revoici avec une bonnes nouvelle: Tous les programmes que nous compilons fonctionnent très bien. Le groupe n'a toujour pas de nom, mais ça arrivera bien à un moment ou à un autre. Je dois dire que pour le moment on se débrouille bien, et nous avons décider de commencer à programmer quelques petites routines. Dumoins les autres membres du groupe , pas moi pour l'instant, car je suis encore en train d'apprendre le C et je ne suis pas encore au point. De plus quand j'étais au chômage j'avais du temps, mais ayant retrouvé, il y a trois jours, un emploi j'en ai moins. Mais c'est la vie. Nous avons aussi décidé de charger nos programme, sur la GC avec PSUL, en format GCM. En effet cela facilite grandement les choses. A+ tout le monde et bonne soirée.

Bonjour à tous. Aracno et afterbuzz merci de votre solicitude et par donnez moi si je ne vous ai pas répondu rapidement. Nous avons recruté pour le son: Jbam . Et un "documentaliste": Contre Courant. Donc Afterbuzz, je suis désolé mais pour l'instant Jbam suffit. Quant à Aracno et Jackass, nous sommes en train de réfléchir au sujet de votre demande car nous sommes déjà 3 programmeurs ... A plutard , et bonne journée à toute la communauté.

Bonsoir à tous. Vous devez connaître l'INPI. Non !!! C'est l'Institut National de la Propriété Industriel. Il y a l'équivalent aux US. C'est l'USPTO. Donc Matsushita, celui qui fait les minidisc pour nintendo avec codebarre, a déposé un brevet: Inventors: Gotoh; Yoshiho (Osaka, JP); Oshima; Mitsuaki (Kyoto, JP); Tanaka; Shinichi (Kyoto, JP); Koishi; Kenji (Sanda, JP); Moriya; Mitsuro (Ikoma, JP) Assignee: Matsushita Electric Industrial Co., Ltd. (Osaka, JP) Appl. No.: 595139 Filed: June 15, 2000 Voici le lien: Inutil de vous dire de vous munir d'un dico anglais http://patft.uspto.gov/netacgi/nph-Parser?...7128&RS=6457128 On devrait avoir ce reflex de chercher un peu partout ... Peut-être que nintendo a déposé des Brevet aux US ... Mais en Europe? Et en France? On a tellement de choses à apprendre