perspective ? - Page 1

Quel methode utiliser vous pour mettre une image en perspective dans vos jeux 3D.
vous utiliser la trigo ou pitagore pour metre en perspective ou vous reduiser sur la longueur une parti du sprite pour donner l'impression d'etre en 3D, ou vous avez une autre methode?
j'aimerais savoir quel est la methode la mieux adapter pour les ti ?

phytagooooore!

produits scalaiiiiiiiiiiiiiiirreees !

trigo???????
pouaaahhh! pas pour la perspective

produit scalaire... je l'avais completement oublier celui la.... merci de me le rapeller sbibi
ça fait 2 ans que j'ai plus vue ça en cours

sinom y a pas d'autre astuce?

bah, je pense pas vraiment...
si il y des astuces + rapides que le produit scalaire ou pythagore (ce qui revient EXACTEMENT au même), ben je suis intéressé aussi...
mais franchement je pense pas... paske g bien étudié le sujet, et pour de la 3D, y a que ça...

et en plus ca peut aller vite si c'est bien fait

ouaish
en 3 instructione en asm, c fait

C'est clair en ASM le code est plus petit qu'en C

Dommage qu'il n'y a pas d'autre methode

par contre, ac 4, c mieux
au fait, qqun peut optimiser ça?:

asl.l #projec_factor,d5;22
asl.l #projec_factor,d6;22
divs.l d1,d5;158
divs.l d1,d6;158

(je sais, y a 2 divisions, c affreux )

ce n'est pas la peine de dire que l'on pourrait faire:

move.l #projec_factor,d0
divs.l d1,d0
muls.l d0,d5
muls.l d0,d6

paske ça va pas pour la perspective
ba ouais, fo que la division soit la dernière opération effectuée, sinon, on a une affreuse approximation qui produit un éloignement saccadé #gerbe#

>SBIBI
tu travaille en valeur exacte ou valeur approcher?

Raah! les majuscules pitié

ben, dès que t'as une fonction perspective, ça implique forcément au moins une division par Z...
donc comme le 68000 de la Ti n'accepte pas jusqu'à preuve du contraire, le calcul en virgule flottante hardware, et que le floating point en asm est bcp trop lent pour ce genre d'applications, tu es forcé de faire une approximation...
sinon, pour tout le reste, le mieux reste encore le calcul avec des entiers, pour la rapidité et la précision
[edit]Edité par sBibi le 18-11-2001 à 09:46:31[/edit]

Vive les operations vectorielles, c plus mieux pour faire ce genre de truc ...

bah ouais, c le produit scalaire...

bah oué, mais j'etais un peu plus general là ...

et le produit vectoriel pour orienter la surface et définir les reflets
mais bon, en gray4 ça le fait pas trop...

mais oui
y a un truc qui s'appelle le tramage

16 ndg ac 4 à la base... ça suffit pour des reflets

le pbl, c surtt que ça bouffe des ressources

au fait, pendant qu'on y est, si qqun a un algo rapide pour faire du tramage, ça m'intéresse bcp

mais vu la taille des polygones que tu vas afficher, je doute que le tramage change réellement qqchose...

bah, ce sera mieux, mais je sais pas si je pourrais le faire... ça va être cho ac les fps...

Déjà qu'afficher des triangles tous cons ça prend une éternité...

une éternité?
meuh non...

En tout cas trop de temps pour faire de la 3D intéressante

meuh non

qu'entends tu par "intéressante" ??

Bah poucoir faire un zoli jeu avec un nombre potable de fps et plus de 4 polygones...

oui

et à ton avis, c koi le nombre de polygones acceptable pour un jeu?
50? 100? 200?
5000?

Ca dépend du jeu
là je bossais sur un Rubik's cube en 3D et j'avais 108 polygones...
Mais on est loin de GT3

sur pc?
c tt 108 polys???
wah! ma map de quake 3 faisait dans les 400 polys !!

Nan sur ti
2 polys par carrés, 9 carrés par face, 6 faces
mais en fait il y a moyen de n'en afficher que la moitié, bien sûr
mais ça tourne pas super...