Réaliser Des Démos Sur Gamecube


Messages recommandés

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.

Lien vers message
Partager sur d'autres sites
  • 2 weeks later...
  • Réponses 186
  • Created
  • Dernière réponse

Top Posters In This Topic

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.

Lien vers message
Partager sur d'autres sites

En y réfléchissant bien grandfrere, on arrive a afficher le cube avec une matrice indéxé et la camera avec une matric non indexee. Si on essaye d'indexé la camera plus rien ne s'affiche alors peut etre qu'on ne peut pas indexe la camera, c'est peut etre obliger.

Au fait j'ai fini le bac blanc mais je l'est totalement foiré ;)

@+ tout le monde

Lien vers message
Partager sur d'autres sites

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. ;)

Lien vers message
Partager sur d'autres sites
  • 2 weeks later...

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. ^_^

Lien vers message
Partager sur d'autres sites
  • 2 weeks later...

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.

Lien vers message
Partager sur d'autres sites
  • 2 weeks later...

Bonjour les amis,

c'est juste un petit message pour vous dire que je viens d'installer le kit de dev GC (OpenGC) sur mon PC au boulot et sur mon Mac chez moi et que sur ces deux environnements j'arrive à compiler sans pb des dol pour la GC.

J'avoue que sur Mac j'en ai bavé un peu car le kit de dev est super mal fichu, sans "ReadMe" avec tout dans un ".pkg" (et je déteste les ".pkg") et j'ai même du changer du code dans l'OpenGC pour arriver à compiler sans pb....bref heureusement que j'avais testé la version PC avant, ça m'a bien aidé.

En tout cas je suis en train de coder un petit hombrew et j'espère arriver à faire des choses interessantes !

Lien vers message
Partager sur d'autres sites

Après quelques tests, c'est finalement chaud de faire quelque chose de correct.

Je n'arrive à afficher que la moitié des images que je veux car les lignes paires sont affichées sur un framebuffer et les lignes impaires dans un autre...et je ne sais pas comment avoir toute l'image à l'écran.

Ensuite j'ai écrit une routine de convertion d'un buffer en RGB vers un framebuffer en Y1CrY2Cb et les performances sont très mauvaises, très en dessous de la trame ce qui me semble incroyable, il doit y avoir une merde quelque part...

Lien vers message
Partager sur d'autres sites

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

Lien vers message
Partager sur d'autres sites
Si j'ai un conseil à te donner , le framebuffer c'est simple et complique... Change de technique !

Il y a moyen de faire autrement que d'utiliser le framebuffer en YCrYcb ?

Après quelques tests avec le framebuffer, je ne vois pas du tout comment réussir à faire une démo à la vbl. Rien que pour swapper deux framebuffers ça prend un temps fou ! Sans compter l'histoire des lignes paires et impaires...

Modifié par Fabrice_75015
Lien vers message
Partager sur d'autres sites

Salut à tous. :wink:

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.

Lien vers message
Partager sur d'autres sites

salut à tous. ;)

Bon je pense que je vais en finir avec l'éclairage. En effet, j'arrive

à éclairer une sphère avec 8 lumières du type spéculaires en rotation

autour de celle-ci. Je fais une petite démo avec une sphère et un cube

avec 8 lumières, et ensuite je passe à la ' TEXTURE '.

Allez, bon courage aux débutants et n'hésitez pas à me poser des questions.

Bisous aux filles.

Lien vers message
Partager sur d'autres sites

Salut Dr Wily.

Tous mes programmes utilisent les API du hardware GCN, car en effet j'utilise

le SDK Nintendo. Donc c'est pour moi assez simple comparé à ceux qui utilisent

devkitcube (qui sont courageux). Par conséquent il n'y a rien de soft pour les applications graphiques.

Pour l'éclairage voici ce qui ce passe:

On peut contrôler 4 canaux : 2 pour la couleur et 2 pour l'aplha.

C'est la fonction GXSetChanCtrl qui affècte les canaux.

L'alpha c'est l'opacité.

CANAUX----> couleur : Color0 et Color1 et alpha: alpha0 et alpha1

Pour chaque canal on peut affecter jusqu'à 8 lumières à l'aide de masques :

GX_LIGHT0 à GX_LIGHT7.

Grace à ces masques on choisit la ou les lumières qui agiront sur les vertices

des modèles qui seront affichés dans le monde 3D.

Voilà. A+

Lien vers message
Partager sur d'autres sites

Merci bien de ta réponce. Sinon je voulait savoir quel type de shaders sont utilisé dans Resident Evil (le 1er) pour les effets sur les décort ce sont des light dynamique ou bien des shaders ?

Par exemple pour l'orage ou les ombrage sur les murs .

Lien vers message
Partager sur d'autres sites

Bonjour les amis,

j'aimerai savoir s'il est possible avec OpenGC d'initialiser l'affichage vidéo avec autre chose que le framebuffer, c'est à dire :

- sans avoir à utiliser le YCrYCb, mais en utilisant du RGB

- et en ayant un temps d'accès réduit à la mémoire vidéo (c'est à dire que ça boost comme ça devrait).

Si la réponse est non, alors est ce que cela est faisable avec le kit officiel facilement ? (si oui, on doit pouvoir faire du reverse engeneering dessus)

Lien vers message
Partager sur d'autres sites

Salut à tous . ;)

Dr wily, le hardware de la GC ne propose que le Gouraud Shading pour la

lumière. A partir de ça, tu as le choix entre une source lumineuse ponctuelle

ou directionnelle. Puis la reflection de la lumière est soit diffuse, soit spéculaire

et soit atténuée à l'aide d'un angle et une distance. C'est ce que j'ai utilisé comme

techniques pour l'éclairage de vetex. Pour les textures je ne sais rien, je suis

en plein dedans. Je pense que les développeurs de jeux utiliserons les mêmes

techniques que moi.

Fabrice, je n'ai pas encore vu à fond la partie Vidéo output, mais pour le

peu que j'ai lu, je crois que la convertion RGB ----> YUV est obligatoire.

D'abord il faut savoir que le Format YUV à presque la même qualité

visuelle que le Format RGB.

Puis pour une image 640x240 (150000 pixels) :

- Un Format RGB 24-bit/pixel demande 900 Ko.

- Un Format YUV 16-bit/pixel demande 600 Ko.

Un gain de 300 Ko.

Aussi, on converti le RGB EFB (Embended Frame Buffer) vers le YUV XFB

(eXternal Frame Buffer).

Voilà

Modifié par GranDFrère
Lien vers message
Partager sur d'autres sites

Oui mais e RVB sur GC (tout du moins les modèle euro) n'a pas de synchro composite comme le YUV, y a t'il vraiment une convertion ou le RVB est il implémenté en natif ?

Lien vers message
Partager sur d'autres sites

Le problème ce n'est pas tant la convertion RGB -> YUV qui est relativment rapide, mais c'est surtout que lorsque l'on écrit à l'adresse 0xC0500000 c'est super lent....c'est tout juste si on ne voit pas les pixels se dessiner les uns après les autres...(j'abuse à peine).

Lien vers message
Partager sur d'autres sites
Invité kurni

arg le problème doit se situer au niveau des videowaitvsync (en + des conversions amha) alors en tt cas ca caa marche très bien ;)

#include "include\mygcn.h"#include "logo.raw.c"#include "libg.h"void logo(int xlogo, int ylogo){int x , y;                                                                                                                                            //int xx,yy;                                                                     for(y=0; y<200; y++)                                                              {                                                                                 yy = y + 1;                                                                                                                                                   for(x=0; x<100; x++)                                                           {                                                                                 xx = x + 1;                                                                    putPixel(x+xlogo,y+ylogo,logo_Bitmap[yy][xx]);                                       }                                                                           }//VIDEO_WaitVSync();}int main(){// video initVIDEO_Init(VIDEO_640X480_PAL60_YUV16);VIDEO_SetFrameBuffer(VIDEO_FRAMEBUFFER_BOTH, (u32)g_pFb);RENDER_ClearFrameBuffer(g_pFb, COLOR_BLACK);int sens=1;int xlogo=100,ylogo=100;while(1){if (sens==1){	logo(xlogo,ylogo);    VIDEO_WaitVSync();    RENDER_ClearFrameBuffer(g_pFb, COLOR_BLACK);	ylogo+=1;}if (sens==-1){    logo(xlogo,ylogo);    VIDEO_WaitVSync();    RENDER_ClearFrameBuffer(g_pFb, COLOR_BLACK);	ylogo-=1;}if (ylogo==400)sens=-1;else if (ylogo==100)sens=1;}}

Lien vers message
Partager sur d'autres sites

L'effet de l'eau que l'on peut voir dans Rebel Strike ou Final Fantasy il est obtenu comment. Je suppose qu'il y a du bump pour le relief mais pour les reflets ?

As tu des info sur la prog des nurb\surfaces paramétrique, que l'on peut voir dans F-zero Gx par exemple ?

Modifié par Dr.Wily
Lien vers message
Partager sur d'autres sites
  • 5 weeks later...

Salut à tous. ;)

Bon ben voilà, j'en ai fini avec l'éclairage et je compte vous donner des démos

techniques d'ici peu: 3 sur l'éclairage et 1 sur les matrices indexées.

Textures me voici pour cet été .... car je n'aurai pas de vacances cette

année, ma fille et ma femme partiront sans moi.

Alors bonne vacances à tous, et il faudra que la rentrée soit prometteuse pour

toutes les consoles.

A bientôt .

Lien vers message
Partager sur d'autres sites
car je n'aurai pas de vacances cette année, ma fille et ma femme partiront sans moi.

Bon courage...

Lien vers message
Partager sur d'autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant

Annonces