Merci

je reponds ici, j´ai la flemme de m´enregistrer . ..

dans l´ordre :

le code d´init du device => reprendre celui genere par le wizard : ca n´apporte rien de le faire soit meme, c´est long fastidieux et chiant...

pour la camera : une camera EST une matrice, tu peux donc l´encapsuler pour en faire une classe pratique ; il y a deja une classe camera dans les common fournit avec le SDK. Il suffit de rajouter qq fonctions pratiques ( comme le frustum clipping) pour avoir rapidement un truc fonctionnel
pour les piles, cf. dans la doc de D3DX les MatrixStack

les warning du debbuger : OUI c´est TRES grave ! Il vous faut un truc pour trier les device state pour ne surtout pas forcer un etat si le device est deja dedans : c´est une perte de temps qui peut s´averer consequente !

pour le reset et les resources, faut cogiter un peu pour savoir ce qui survit ou pas ( genre des textures en POOL SYSTEM_MEM peuvent survivre, de meme que des shaders compiles, les buffers par contre, ca depend la encore du type... Bref, c´est se prendre la tete pour rien : vous resetez proprement SANS detruire les objets, et ca doit marcher comme il faut

Desole de pas avoir repondu plus tot...

Merci, pour ta reponse.
Mais je comprends pas quand tu me dit :
" Il vous faut un truc pour trier les device state pour ne surtout pas forcer un etat si le device est deja dedans "

Sinon, je me suis mis au SDK 9.0c : J´ai l´impression que directX va remplacer l´API win32 dans un avenir tres proche. A quand une nouvelle version des MFC qui encapsulera DirectX ?

Mais je comprends pas quand tu me dit :
" Il vous faut un truc pour trier les device state pour ne surtout pas forcer un etat si le device est deja dedans "

ca veut dire qu´il ne faut pas envoyer tes polys a la carte directement, tu stockes les ordres de rendus dans une structure a toi, quand tous les ordres pour la frame en cours sont connus, tu les tries selon leurs attributs ( textures, etats des samplers, param de rendu tels que alpha stencil etc. ) , et ensuite tu les envoyes a la carte : ca t´evite de changer 20 fois de texture alors que c´est la meme qu´est utilisee, ou d´activer l´alpha une fois sur deux maintenant que les objets en ayant besoin sont groupes

Ok

Sa devien de plus en plus complique... Tant mieux

C´est une technique courante de stocker tout l´affichage ? Dans aucun tutorial j´ai entendu parler de ca.

Ce n´est pas vraiment " stocker l´affichage" mais plutot " bufferiser les ordres", et oui c´est TRES courant, c´est meme indispensable et c´est donc present dans tous les programmes dignes de ce nom ( et je ne connais pas un seul jeu dont les sources sont dispo qui n´integre pas un tel systeme, plus ou moins complexe).
En gros tu peux voir ca comme une couche d´abstraction supplementaire ; l´avantage, ce que tu peux " post-processer" les ordres de dessins ( comme ici, regrouper les elements par attributs pour eviter de forcer des etats du device redondants), mais en plus en fournissant cette couche tu peux egalement assurer une interface de programmation stable et durable ( si qqun d´autre que toi utilise ton code, ca peut etre TREEEES pratique)

et si les tutorials n´en parlent pas, c´est justement que c´est des tutorials... la ca commence a devenir un peu serieux, donc il n´y a pas de solution miracle, il y a bien une base de principes commun pour trier ses elements dans sa couche renderer, mais apres chacun y va de sa sauce maison, selon les donnees de son probleme...

" Sinon, je me suis mis au SDK 9.0c : J´ai l´impression que directX va remplacer l´API win32 dans un avenir tres proche"

bin dans la prochaine version de Windows ( Longhorn) tout le sytème de fenêtrage sera basé sur DirectX . .. Autant dire que les effets à la con vont voir le jour

J´ai pu voir une démo de ce que ca donnait, et pour exemple les gars qui faisaient la présentation avaient appliqué une rotation de la fenêtre ! Imagine un Word en train de tourner sur lui même, pratique pour taper

Merci pour vos info