Matrices de rotations et projections - Page 3

J'ai déjà une ancienne version de Blender mais je trouve qu'il n'est pas très pratique pour obtenir les coordonnées des vertices et des faces.

Sinon, je suis arrivé à remplir les polygones avec des lignes horizontales en niveaux de gris !!!

J'ai un petit problème avec les déplacements dans mon moteur:

Pour tourner à droite ou à gauche je fait une rotation de la sphère autour de la caméra. C'est bien comme ça qu'il faut faire ?
Et puis par contre pour avancer je ne sais pas comment faire. Je sais qu'il faudrait aller dans la direction de l'angle ou l'on se trouve mais en pratique je ne sais pas comment faire.
En ce momment pour avancer ou reculer je fait un zoom en avant ou en arrière... en on n'a pas l'impression d'avancer doit.
Peut-être qu'il faut que j'ajoute l'angle dans lequel la caméra vise au x,y et z de la caméra, non ?

Pour les déplacement, il faut utiliser la trigonométrie. (x+=cos[dirx]*pas par exemple)
Comment sont stockées tes donnée ?
Je te conseille d'utiliser des nombres à virgule fixe pour avoir un minimum de précision tout en ayant une bonne rapidité (moi, je n'utilise que 5 bits pour la partie décimale et je trouve que ça suffit en termes de précision).

Euh, je comprend pas là. Pour avancer dans la direction où l'on est il faut modifier la caméra ? Et on modifie quoi qd on avance ou recule: les x, les y, les z, les 3 ?
Et la formule c'est quoi.

Sinon la plupart des données sont stoquées dans des tableaux du genre

typedef struct
{

long x,y,z;

} Tableau3DLong;

Raphaël
a écrit : Euh, je comprend pas là. Pour avancer dans la direction où l'on est il faut modifier la caméra ?

Tu peux faire comme ça, ou bien transformer tous les objets...
Je ne sais pas lequel est le mieux.
Peut-être que c'est simplement de faire bouger tous les objets... Faut tester.

Et on modifie quoi qd on avance ou recule: les x, les y, les z, les 3 ?

Ben ça dépend de la direction dans laquelle on avance !
Si on avance dans la direction de l'axe X, alors oui, il ne faut incrémenter/décrémenter que la composante sur X. Mais si on veut avancer en diagonale, il faudra forcément incrémenter la position de la caméra (ou décrémenter la pos de tous la map) sur 2 axes.

Et la formule c'est quoi.

Ben ça dépend un peu de ton moteur, ça doit correspondre à peu près à ce que j'ai mis au post précédent. Fais un shéma et essaie de trouver la formule toi-même, c'est mieux. Il faut utiliser la trignonmétrie (enfin, il y a p-ê d'autres techniques, mais je ne les connais pas).

Sinon la plupart des données sont stoquées dans des tableaux du genre

typedef struct
{

long x,y,z;
} Tableau3DLong;

OK, mais tu travailles sur des nombres naturels ou bien décimaux ?

J'ai essayé de trouver quelque chose sur un schéma mais j'ai jamais trouvé ce qu'il fallait faire.
Le mieux ce serait de toucher uniqument la caméra puisqu'il y a qu'un point à transformer.

Pour le raycating c'est facile de lancer un rayon: on multiplie le sin de l'angle au pas (Y) et on multiplie le cos de l'angle au pas de X, et on ajoute les deux coordonnées à la position de la caméra.

Mais là je ne voit pas comment faire...

Pour le moment j'ai un seul objet et je ne sais pas comment je pourrais en gérer plusieurs.

Voilà comment j'utilise mes données:






if GX_RIGHTpressed()
{
vue--;
if(vue<0)
{
vue=359;
}
}
if (GX_LEFTpressed())
{
vue++;
if(vue>359)
{
vue=0;
}
}
if(GX_UPpressed())
{

camera.z=camera.z-3;

}
if(GX_DOWNpressed())
{
camera.z=camera.z+3;
}

if GX_ALPHApressed()
{
camera.x=camera.x-3;



}
if GX_DIAMONDpressed()
{
camera.x=camera.x+3;

}


...



//=========== Translation = Caméra =========================
x1 = Transform[t].x + (camera.x<<7);
y1 = Transform[t].y + (camera.y<<7);
z1 = Transform[t].z + (camera.z<<7);
//===========================================================

//============ Rotation de l'objet par rapport à la caméra autour de l'axe des Y ===============
// +Première division par 128
x = ((x1*Cos[vue]+z1*Sin[vue])>>7);
y = y1;
z = (((-x1)*Sin[vue] + z1*Cos[vue])>>7) ;
//========================================================================


//=========================== Projection=====================================
Pixel[t].x = (x)/(z>>7) + 80; //Pixel[t].x = ((x/128) *128)/(z>>7) + 80;
Pixel[t].y = (y)/(z>>7) + 50; //Pixel[t].y = ((y/128) *128)/(z>>7) + 50;
//===========================================================================

C'est le foutoir complet car je fait les divisions un peu n'importe quand.
Les divisions que je fait lors de la projection divise les angles que je multplie lors des rotation de l'objet sur lui même.

Si je fait ça n'importe comment c'est que je fais ça comme ça vient et maintenant que mon moteur c'est agrandit c'est dur à gérer.


Enfin je suis quand même très content de ce que j'ai fait même si maintenant je suis un peu coincé parce-que j'ai un peu mal strucutré mon code et tout n'est pas très clair.

Mais maintenant mon moteur est texturé (enfin en une couleur) en niveaux de gris.
Le remplissage des triangles est tellment rapide que mon moteur tourne plus vite avec les textures + Back Face Culling qu'en Fil de fer !!!!

J'ai passé deux jours dessus (pour trier les point des triangles dans l'ordre décroissant des Y et puis pour remplir le triangle).
J'utilise le tracé de ligne d'extgraph que j'ai simplifé au maximum. Il y a même une fonction qui dessine dans le plan clair est une autre dans le plan foncé.

Du coup lorsque ma sphère (qui comporte 24 faces) est affichée de manière à ce qu'elle prennent tout l'écran, le moteur affiche 35 Fps !!!



Bon et bien je vais continuer à réfléchir pour les déplacements.

Raphaël a écrit :
J'ai essayé de trouver quelque chose sur un schéma mais j'ai jamais trouvé ce qu'il fallait faire.
Le mieux ce serait de toucher uniqument la caméra puisqu'il y a qu'un point à transformer.
Pour le raycating c'est facile de lancer un rayon: on multiplie le sin de l'angle au pas (Y) et on multiplie le cos de l'angle au pas de X, et on ajoute les deux coordonnées à la position de la caméra.

OK, je pense que je vois ton pb. Il faudrait que tu stockes plusieurs angles.
Je pense qu'on pourrait se débrouiller avec 2 angles pour les 3 axes, mais tu peux utiliser un angle par axe. Et à partir de ça, je pense qu'on peut facilement faire un truc qui marche.
Mais dans le cas où on marche dans un monde, c'est comme pour le raycasting.

Voilà comment j'utilise mes données:

if GX_RIGHTpressed()
{
vue--;
if(vue<0)
{
vue=359;
}
}
if (GX_LEFTpressed())
{
vue++;
if(vue>359)
{
vue=0;
}
}
if(GX_UPpressed())
{

camera.z=camera.z-3;

}
if(GX_DOWNpressed())
{
camera.z=camera.z+3;
}

if GX_ALPHApressed()
{
camera.x=camera.x-3;



}
if GX_DIAMONDpressed()
{
camera.x=camera.x+3;

}


...



//=========== Translation = Caméra =========================
x1 = Transform[t].x + (camera.x<<7);
y1 = Transform[t].y + (camera.y<<7);
z1 = Transform[t].z + (camera.z<<7);
//===========================================================

//============ Rotation de l'objet par rapport à la caméra autour de l'axe des Y ===============
// +Première division par 128
x = ((x1*Cos[vue]+z1*Sin[vue])>>7);
y = y1;
z = (((-x1)*Sin[vue] + z1*Cos[vue])>>7) ;
//========================================================================


//=========================== Projection=====================================
Pixel[t].x = (x)/(z>>7) + 80; //Pixel[t].x = ((x/128) *128)/(z>>7) + 80;
Pixel[t].y = (y)/(z>>7) + 50; //Pixel[t].y = ((y/128) *128)/(z>>7) + 50;
//===========================================================================

C'est le foutoir complet car je fait les divisions un peu n'importe quand.
Les divisions que je fait lors de la projection divise les angles que je multplie lors des rotation de l'objet sur lui même.
Si je fait ça n'importe comment c'est que je fais ça comme ça vient et maintenant que mon moteur c'est agrandit c'est dur à gérer.

Juste un petit conseil pour tester l'appui des touches : au lieu de faire un appel à une fonction à chaque fois que tu as besoin de savoir si une touche est pressée, je te conseille de lire une seule fois le port, de mettre le résultat dans une var. Et de faire un & avec le résultat de la lecture. Tu gagneras presque rien, mais bon, si tu cherches absolument à optimiser...

Enfin je suis quand même très content de ce que j'ai fait même si maintenant je suis un peu coincé parce-que j'ai un peu mal strucutré mon code et tout n'est pas très clair.

Mais maintenant mon moteur est texturé (enfin en une couleur) en niveaux de gris.
Le remplissage des triangles est tellment rapide que mon moteur tourne plus vite avec les textures + Back Face Culling qu'en Fil de fer !!!!

J'ai passé deux jours dessus (pour trier les point des triangles dans l'ordre décroissant des Y et puis pour remplir le triangle).
J'utilise le tracé de ligne d'extgraph que j'ai simplifé au maximum. Il y a même une fonction qui dessine dans le plan clair est une autre dans le plan foncé.

Du coup lorsque ma sphère (qui comporte 24 faces) est affichée de manière à ce qu'elle prennent tout l'écran, le moteur affiche 35 Fps !!!

Elle a l'air vachement bien optimisée, ta routine, bravo !

Bon et bien je vais continuer à réfléchir pour les déplacements.

Bonne chance.

jackiechan
a écrit : Juste un petit conseil pour tester l'appui des touches : au lieu de faire un appel à une fonction à chaque fois que tu as besoin de savoir si une touche est pressée, je te conseille de lire une seule fois le port, de mettre le résultat dans une var. Et de faire un & avec le résultat de la lecture. Tu gagneras presque rien, mais bon, si tu cherches absolument à optimiser...

Cf. http://tigcc.ticalc.org/doc/kbd.html#_keytest_optimized.

Je pense que pour les déplacements c'est tout bon: en fait il suffit de faire bouger la caméra autour des axes.
Je ne pense pas qu'il y ait besoin d'angle. Je sais pas comment ont fait les programmeurs qui ont déjà fait un moteur 3D mais c'est tout l'inverse du raycasting.

J'avais commencé à programmer en BASIC 83+ l'algo du raycasting mais pour les déplacements je ne savais pas tellement comment faire, non plus.
Pire encore: pour afficher les murs en fonctions des coordonnées trouvées.

Si il fallait avancer en fonction d'un gle cela voudrait dire que les objets de la scène sont fixes comme dans une map pour un jeu en ray-casting.
Mais là si on applique déjà des rotations au objets ce n'est déjà pas pour rien.
Les objets sont positionnés lors des rotation et ensuite il y a juste besoin de faire bouger la caméra sur un axe.

Par contre pour faire une rotation avec la caméra autour d'un objet je n'ai pas encore compris comment faire.
Moi je fait tourner l'objet sur lui même et c'est la première transformation qu'il subit.


C'est vrai que je cherche absolument à tout optimiser au maximum. Pour les touches avant j'utilisais _keytest() puis comme je savais que GX_rowread() était plus rapide et bien j'ai utiliser GX_rowread().

_keytest_optimized je connaissait déjà mais je ne savais pas que l'on pouvait stoquer la valeur dans une variable !

Dans la doc il n'y a que ça:
for (;
{
BEGIN_KEYTEST
if (_keytest_optimized (RR_LEFT)
|| _keytest_optimized (RR_RIGHT)
|| _keytest_optimized (RR_UP)
|| _keytest_optimized (RR_DOWN))
break;
END_KEYTEST
}

... et ils ont pas l'air de dire ça ?

Si c'est possible de le faire c'est clair que je le ferais tout de suite. En tout je crois que j'utilise 12 touches.

Sinon la routine du tracé horizontale de ligne est déjà très rapide mais je l'ai simplifié.
Je pourrais encore l'optimiser en limitant le tracé que dans un seul sens mais dans ce cas là il faut que je trie les X de mes sommets dans le programme.

Pour ceux que ça intéresse la voici:


void FastDrawLineLH(short x1,short x2,short y) {
static const unsigned short table1[16] = {0xffff,0x7fff,0x3fff,0x1fff,
0x0fff,0x07ff,0x03ff,0x01ff,
0x00ff,0x007f,0x003f,0x001f,
0x000f,0x0007,0x0003,0x0001};
static const unsigned short table2[16] = {0x0000,0x8000,0xc000,0xe000,
0xf000,0xf800,0xfc00,0xfe00,
0xff00,0xff80,0xffc0,0xffe0,
0xfff0,0xfff8,0xfffc,0xfffe};
short dx;
short sx;
unsigned short* p;

if (x1>x2) { // on pourrait enlever cette partie si toutes les lignes étaient dessinées de droite à gauche.
short tmp = x1;
x1 = x2;
x2 = tmp;
}

p = (unsigned short*)(Lbuffer+(y<<5)-(y<<1)+((x1>>3)&0x1e));
dx = x2-x1+1;
sx = x1 & 0x000f;

if (dx<16) {
unsigned long val = (ASM_SWAP(table2[dx])) >> sx;

*(unsigned long*)p |= val;

return;
}


if (sx) {
*p++ |= table1[sx];
dx -= (16-sx);
}
while (dx >= 16) {
*p++ |= 0xffff;
dx-=16;
}
if (dx) *p |= table2[dx];

}

Celle-ci dessine uniquement dans un buffer qui est affiché dans le LIGHT_PLANE.
Bien entendu le buffer est déclaré dans le header et la taille de mémoire allouée est défénit dans le fichier C.
D'ailleurs il faudrait que je recopie toutes mes fonctions dans un header mais j'ai bcp de difficulté.

Raphaël a écrit :
_keytest_optimized je connaissait déjà mais je ne savais pas que l'on pouvait stoquer la valeur dans une variable !

Dans la doc il n'y a que ça:
for (;
{
BEGIN_KEYTEST
if (_keytest_optimized (RR_LEFT)
|| _keytest_optimized (RR_RIGHT)
|| _keytest_optimized (RR_UP)
|| _keytest_optimized (RR_DOWN))
break;
END_KEYTEST
}
... et ils ont pas l'air de dire ça ?

C'est parce que _keytest_optimized fait tout pour toi! Ça stocke automatiquement le résultat du test dans une variable pour le prochain test! Il suffit de faire attention à ce que les tests qui testent les touches dans la même ligne se suivent pour que ce soit efficace.

Ça stocke automatiquement le résultat du test dans une variable pour le prochain test!
Donc ça ne peut pas stoquer la valeur dans une variable que l'on a déclarer ?

Il suffit de faire attention à ce que les tests qui testent les touches dans la même ligne se suivent pour que ce soit efficace.
Ah, oui donc on ne fait pas qu'un test, qui est enregistrer dans une var alors ?

... Je vois pas comment l'utiliser...

Et puis a ce qui paraît rowread fait perdre 250 cycles pour rien ? Ca vient de quoi ?
En tout cas avec toutes les touches que le programmes doit gérer il y a une grosse différence de rapidité entre _keytest() et GX_rowread !

Raphaël a écrit :
Ça stocke automatiquement le résultat du test dans une variable pour le prochain test! Donc ça ne peut pas stoquer la valeur dans une variable que l'on a déclarer ?

Si tu veux faire ça, tu utilises _rowread directement.

Il suffit de faire attention à ce que les tests qui testent les touches dans la même ligne se suivent pour que ce soit efficace.
Ah, oui donc on ne fait pas qu'un test, qui est enregistrer dans une var alors ?

Si, justement, la macro _keytest_optimized fait ça automatiquement, à condition que le test soit dans la même ligne de touches que le test d'avant!

... Je vois pas comment l'utiliser...

while (boucle du jeu) {
BEGIN_KEYTEST
// ligne des curseurs et modifiants
if (_keytest_optimized(RR_LEFT) {
// gauche
} else if (_keytest_optimized(RR_RIGHT)) {
// droite
} else if (_keytest_optimized(RR_UP)) {
// haut
} else if (_keytest_optimized(RR_DOWN)) {
// bas
} else if (_keytest_optimized(RR_2ND)) {
// 2nd
}
// autres lignes
else if (_keytest_optimized(RR_7)) {
// 7
} else if (_keytest_optimized(RR_X)) {
// x
}
}

Et puis a ce qui paraît rowread fait perdre 250 cycles pour rien ? Ca vient de quoi ?

Pas pour rien. Pour la boucle d'attente nécessaire pour faire réagir le matériel. AMS attend encore plus que TIGCC pour la lecture du clavier!

Ah, ok. Merci bien !

Et cette méthode est plus rapide que d'utiliser _rowread et de stoquer la valeur dans une variable ou pas ?

J'ai remplacé GX_rowread par _keytestoptimized() et je n'ai pas l'impression que ça soit plus rapide qu'avant. En tout cas ça n'affiche pas une frame de plus sur le compteur.

Si ça se peut c'est même plus lent... et pour la touche ESC je suis obligé d'utiliser keytest parce-qu'elle ne se fait pas dans la même boucle que les autres touches...

Et puis les else if, ça sert à rien ? ... a part prend plus de place ?

Raphaël a écrit :
Ah, ok. Merci bien !
Et cette méthode est plus rapide que d'utiliser _rowread et de stoquer la valeur dans une variable ou pas ?

D'arpès ce qu'a dit Kevin, ça a l'air de revenir au même. Sauf que t'as pas à te faire chier pour chercher quand plusieurs touches sont sur la même ligne : TIGCC le fait tout seul.

J'ai remplacé GX_rowread par _keytestoptimized() et je n'ai pas l'impression que ça soit plus rapide qu'avant. En tout cas ça n'affiche pas une frame de plus sur le compteur.
Si ça se peut c'est même plus lent... et pour la touche ESC je suis obligé d'utiliser keytest parce-qu'elle ne se fait pas dans la même boucle que les autres touches...

Bizarre. Essaie en stockant la valeur de _rowread(ligne) dans une var et en faisant un & avec.
Les touches 2nd, alpha, shift, diamant et les flèches directionnelles sont sur la même ligne.

Moi, je sais que ça m'a fait gagner qq fps (3%, par là).

Et puis les else if, ça sert à rien ? ... a part prend plus de place ?

Si, c'est un tout petit peu plus rapide. Si par exemple tu as 5 tests à la suite (if(...)... else if(...)... else if(...).....). Si le 2ème test est vrai, les 3 derniers ne seront pas testés, tandis que sans les 'else', à chaque fois on ferait les 5 tests.

La raison pour laquelle GX_rowread est plus rapide est que la boucle d'attente (pour laisser réagir le matériel) de _rowread (qui est utilisé par _keytest et _keytest_optimized) attend plus longtemps que celle de GX_rowread.

Le mieux serait que je retourne a GX_rowread alors ?
Sinon j'ai retrouvé un éditeur de polygones qui fait partie de 3D Game Studio que j'ai trouvé sur un CD qui est assez simple à utiliser et qui convertit les vertices et les faces au format ASC.

Oui, mais tu peux ne faire qu'un seul appel à GX_rowread pour lire si les flèches directionnelles et les touches 2nd, alpha, shift et diamant sont enfonçées.
Comme ça :

short touches;
...
touches=GX_rowread(0x7E);
if(touches & 0x1) // HAUT
...
if(touches & 0x2) // GAUCHE
...
if(touches & 0x4) // BAS
...
if(touches & 0x8) // DROITE
...

J'avais compris ton truc mais je n'était pas sûr qu'il fallait faire comme ça.
Merci !

Salut!
Y a une question de Raphaël qui m'interessait et qui je crois n'a pas trouve de réponse:
Quel est l'avantage des matrices de transformations par rapport aux formules simples?
Parce que ca a l'air + lourd et + lent =>???

Sinon, t'a precalculé les sin et les cos? paske c hyper lent

Et pour bouger la camera, ta besoin des angles! (et c comme pour le raycast)
En effet, tu veut avancer en fonction de l'orientation de ta camera!
(je sais pas si je suis bien clair, la)
Sinon, le seul mouvement,c les mvts sur x,y et z, meme si ta camera a un angle de 35° par ex

Salut à toi aussi.

Quel est l'avantage des matrices de transformations par rapport aux formules simples?
Oui ça m'intéresserais aussi ! Pour l'instant j'utilise tjrs des fonctions et j'ai trouvé des formule pour multiplier les matrices mais je ne vois pas encore comment cela permet de gagner de la rapidité

Oui j'ai précalculé les sin et les cos et les multipliant par 128 pour avoir des entiers. Par contre après on ne sait jamais où et quand diviser.
Les fonction cos et sin sont très lente mais je suis passé de 3 à 7 fps en précalculant les angles. Le plus gros gain que j'ai pu faire ça été de passer des float au short (j'utilise quelques long aussi). Et la j'ai du passer de 7 fps à 120 si je me rappelle bien.

Et pour bouger la camera, ta besoin des angles! (et c comme pour le raycast)
En effet, tu veut avancer en fonction de l'orientation de ta camera!
(je sais pas si je suis bien clair, la)
Sinon, le seul mouvement,c les mvts sur x,y et z, meme si ta camera a un angle de 35° par ex

Tu es sûr ? Tu as déjà fait un moteur 3D ?
Je pensais qu'en tournant sur soit même orinentait l'objet sur un cercle et puis qu'après il suffisait d'avancer ou de reculer. C'est ce que je fais en ce moment.

Alors comment je fait pour avancer et reculer ? Parce-que là pour avancer je décrémente le z de la caméra et je fais l'inverse pour reculer.

Scuse moi, G pas réflechi et g dis une betise
En fait g deja fait un raycast et je confond son mode de déplacement avec la 3d
C'est donc toi qui a raison, puisque c le monde qui bouge autour de nous quand on se
déplace.

Ok. Ca confirme donc ce que je pensais. En plus ça tombe bien c'est plus simple à gérer comme ça !

Par contre quand je "strafe" à gauche ou à droite et que je fait une rotation à la scène (quand je tourne sur moi même avec la caméra en fait) il y a des petits problème.
Au bout d'un moment quand je combien les deux il arrive qu'au lieu d'avancer je recule et vis versa.
Donc je me demande finalment si il faudrait pas utiliser des angles pour faire un "strafe".
Es-ce que quelqu'un qui aurait fait un moteur 3D, pourrait m'expliquer exactement comme il faut faire pour gérer les déplacement (avancer, reculer, strafer, tourner...).

Je suis trop content !!!!!!!
J'ai trouvé comment faire !

En fait comme j'ajoute la caméra avant la rotation (on est obligé évidement) et bien on est obligé de corriger ce que subit la caméra à cause de la rotation.

J'ai donc écrit mes formules au feeling et voici ce que ça donne:

if (touche & 0b00000010) // GAUCHE
{
vue++;
if(vue>359)

{
vue=0;
}
}
if(touche & 0b00001000) // Droite

{
vue--;
if(vue<0)
{
vue=359;
}
}
if (touche & 0b00000001) // HAUT
{
camera.z=camera.z-Cos[vue];
camera.x=camera.x+Sin[vue];
}
if(touche & 0b00000100) // BAS

{
camera.z=camera.z+Cos[vue];
camera.x=camera.x-Sin[vue];
}

if (touche & 0b01000000) // Diamond
{
camera.x=camera.x-Cos[vue];
camera.z=camera.z-Sin[vue];
}
if (touche & 0b10000000) // Alpha
{
camera.x=camera.x+Cos[vue];
camera.z=camera.z+Sin[vue];
}


...


//=========== Translation = Caméra =========================
x1 = Transform[t].x + (camera.x);
y1 = Transform[t].y + (camera.y<<7);
z1 = Transform[t].z + (camera.z);
//===========================================================

//============ Rotation de l'objet par rapport à la caméra autour de l'axe des Y ===============
// +Première division par 128
x = ((x1*Cos[vue]+z1*Sin[vue])>>7);
//y = y1;
z = (((-x1)*Sin[vue] + z1*Cos[vue])>>7) ;
//========================================================================




//=========================== Projection=====================================
Pixel[t].x = x/(z>>7) + 80; //Pixel[t].x = ((x/128) *128)/(z/128) + 80;
Pixel[t].y = y1/(z>>7) + 50; //Pixel[t].y = ((y/128) *128)/(z/128) + 50;
//===========================================================================

Je ne suis pas sur de comprendre tes mvts...
gauche et droite pour les rotations, c ok
mais pour les autres, t'utilises des angles, et je comprends pas pkoi
Normalement : Strafer à gauche : camera.x--, à droite : camera.x++,
et pareil pour avance/reculer et monter/descendre

Jusqu'à aujourd'hui je pensais comme toi.
Lorsque l'on ne gère pas angles on peut faire comme ça et ça marche.

Mais lorsque l'on utilise une rotation, l'angle de la rotation va modifier l'axe sur lequel on se déplace. En donc on doit se déplacer dans le même sens que l'angle de la rotation comme pour le ray-casting en fait.

Avant j'avais fait des tests et lorsque je tournait puis je faisait un strafe je voyais que le strafe déplacait l'objet en fonction de l'angle de la rotation.
Comme je me déplaçais sur un axe qui était "droit" j'en ai conclut que pour avoir un strafe "droit", il fallait que je me déplace sur un angle.
Ne me demande pas pourquoi utiliser ces formules, là j'ai fait ça au hasard !
Il faudrait que je regarde à quoi ça correspond en fait

Moi non plus je n'arrive pas encore à me mettre dans la tête ce que j'ai fait mais je commence à comprendre


Peut-être que l'on peut aussi faire comme tu dis (et comme je faisais avant) mais il faudrais que je change l'ordre des transformations et je sais pas si c'est possible d'obtenir le même résultat.

En ce moment je fait un première rotation de l'objet sur lui-même, puis j'ajoute la caméra, puis je fait une rotation autour de la caméra (ce qui permet de tourner sur soi même) et enfin je projette les coordonnées 3D sur un plan 2D pour pouvoir dessiner les faces.

Et donc comme tu peux le voir l'ajout de la caméra se fait avant la rotation. Si l'on fait z++; pour reculer la rotation va modifier z zt quand on va reculer l'objet va prendre la direction de l'angle de la rotation.

Bon, c'est peut-être pas très clair mais vu que j'ai du mal à le comprendre aussi, c'est dur de l'expliquer.

C vrai que g un peu de mal a comprendre...
Mais apparemment t'as des problemes parque tu fait des rotations avant les translations.
Or tu dois translater avant de rotater! ()
C pas ce que tu faisait avant?
Donc, tu detecte les touches, tu modifies la camera pour sa translation, et tu stocke la modification de son angle (si il est modifié)
Ensuite tu translate tes points, puis tu fait les rotations puis to projetes, et la
ca devrais marcher
Faudrais demander à Sbibi, paske la...

La translations c'est bien l'ajout de la caméra ?
Si c'est le cas je fait bien les choses dans l'ordre sans quoi ça ne marcherait pas.
En tout cas ce que j'ai fait marchre mais c'est vrai que je devrais demander pour savoir si c'est bien bon.

AAAhhhh je crois que g compris le prob!
Mais alors, avant ca devais bugger juste en stafant egalement!
Le truc, c que pour faire les deplacement avec camera.x++,etc, il faut que le monde soit centré sur la camera, et avec le bon angle!!!
Or les modifications de la caméra ne modifient pas les vertices!!
Donc le truc serait de faire une translation pour mettre la caméra au centre, puis de faire une rotation pour mettre le bon angle.
Puis, ajouter les modification de la caméra, d'abord les translations puis les rotations!
OUF!!!
Bon ca c une théorie, faut voir pour la pratique...
Mais ma methode est-elle meilleure?ca je c pas
SBIBI AIDE NOUS!!!!! (ou n'importe qui qui sache :-) )

J'ai PM sbibi, qu'il nous aide un peu :-)