BumpMANN
Messages postés330Date d'inscriptionjeudi 22 mai 2003StatutMembreDernière intervention26 janvier 2009 16 févr. 2006 à 02:52
pour les renderstate je pense que ca va pas le tuer de se prendre quelques octels a chaque frames mais c'est toujours une optimisation de gagnée, ca se comprend ^^;
pour toutes les stratégies de tri, bonne questions et propositions, faudra que j'essaie un de ces jours ^^ (en plus ca tombe bien je fais un moteur 3D ^^)
Galmiza
Messages postés573Date d'inscriptionsamedi 16 novembre 2002StatutMembreDernière intervention 9 avril 20081 11 août 2005 à 20:25
Salut Bumpmann,
Ca fait longtemps que le dernier message a ete poste donc tu dois avoir trouve des reponses aux questions que tu te posais a l`epoque.
Pourquoi faut-il de preference utiliser un grand vertex buffer statique par FVF qu1un FVF par objet ? Evidemment, ca permet de reduire le nombre de vertex buffer donc de changements de VB, mais est-ce qu`economiser une 100n (pour plusieurs centaines d`objets) d`envoi d`adresse (4 octets) a la carte video par frame augmente de facon considerable le fps ?
Idem pour les changements de renderstate (le port AGP ne peut quand meme pas pleurer pour quelques centaines d`octets ... ).
Dans les jeux d`avions, utilisent-ils le z-buffer (ou trient-ils les meshes par profondeurs)?
Quelle est la meilleure strategie:
-trier les subsets des meshes par texture (contradiction avec large FVF VB)
-trier par shader (changement de shaders)
-par constante dans les shaders (bah ouais 1 matrice 4x4 = 64 octets)
-par streamsource (vertex buffer)
-par indexbuffer (oui, on peut tout mettre sur le meme index buffer)
-par declaration de vertex
As-tu deja tester ces differentes techniques ?
Connais-tu la nature et la quantite de donnees qui transitent par le bus pour chacune de ces fonctions.
Et pour la route, penses-tu qu`un seul et unique FVF permet, a defaut d`economiser la memoire, de gagner en performances ? En effet, dans les vertex shaders, on peut ou pas faire des calculs sur les normales; donc l`affichage d`un objet qui ne necessite pas de normales n`est pas cense prendre plus de temps que si son VB n`avait pas de normales.
Bon et bien merci d`avoir lu jusqu`ici.
Guillaume
BumpMANN
Messages postés330Date d'inscriptionjeudi 22 mai 2003StatutMembreDernière intervention26 janvier 2009 23 févr. 2004 à 21:25
oh non! c'est pas obligatoire! ^_^;; c'est pour les shaders... pour programmer ses effets... genre le bumpmapping self-shadow ou le morphing... enfin bref, de toute facon, dans le directx 9 ya maintenant le HLSL, qui permet de faire tout ca en c++... mais s'il faut optimiser un max, alors il faut passer par l'ASM ;)
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 23 févr. 2004 à 21:21
www.traductionsfrance.com, le nouveau site du résea CodeS-SourceS
;-)
j'ai lu ton RTF (même si en fait je n'utilise pas DX) et j'ai été étonné de voir des bouts d'ASM. C'est obligatoire quand on prog en DX??
16 févr. 2006 à 02:52
pour toutes les stratégies de tri, bonne questions et propositions, faudra que j'essaie un de ces jours ^^ (en plus ca tombe bien je fais un moteur 3D ^^)
11 août 2005 à 20:25
Ca fait longtemps que le dernier message a ete poste donc tu dois avoir trouve des reponses aux questions que tu te posais a l`epoque.
Pourquoi faut-il de preference utiliser un grand vertex buffer statique par FVF qu1un FVF par objet ? Evidemment, ca permet de reduire le nombre de vertex buffer donc de changements de VB, mais est-ce qu`economiser une 100n (pour plusieurs centaines d`objets) d`envoi d`adresse (4 octets) a la carte video par frame augmente de facon considerable le fps ?
Idem pour les changements de renderstate (le port AGP ne peut quand meme pas pleurer pour quelques centaines d`octets ... ).
Dans les jeux d`avions, utilisent-ils le z-buffer (ou trient-ils les meshes par profondeurs)?
Quelle est la meilleure strategie:
-trier les subsets des meshes par texture (contradiction avec large FVF VB)
-trier par shader (changement de shaders)
-par constante dans les shaders (bah ouais 1 matrice 4x4 = 64 octets)
-par streamsource (vertex buffer)
-par indexbuffer (oui, on peut tout mettre sur le meme index buffer)
-par declaration de vertex
As-tu deja tester ces differentes techniques ?
Connais-tu la nature et la quantite de donnees qui transitent par le bus pour chacune de ces fonctions.
Et pour la route, penses-tu qu`un seul et unique FVF permet, a defaut d`economiser la memoire, de gagner en performances ? En effet, dans les vertex shaders, on peut ou pas faire des calculs sur les normales; donc l`affichage d`un objet qui ne necessite pas de normales n`est pas cense prendre plus de temps que si son VB n`avait pas de normales.
Bon et bien merci d`avoir lu jusqu`ici.
Guillaume
23 févr. 2004 à 21:25
23 févr. 2004 à 21:21
;-)
j'ai lu ton RTF (même si en fait je n'utilise pas DX) et j'ai été étonné de voir des bouts d'ASM. C'est obligatoire quand on prog en DX??