bonjour

je programme en ce moment en directX 9, et apparament, le buffer qui est affiché sur la fenêtre a la fin du rendu est d'une conception proche du BMP, alors j'aimerais appliquer des matrices de convolution dessus pour faire des jeux avec des styles graphiques marrants

mais je bloque à l'étape de la récupération de ce buffer, en fait... quelqu'un aurait une méthode sous la main?

lui, a la limite, il arrive a enregistrer des fichiers bmp pour prendre des screenshots:

http://www.gamedev.net/community/forums/topic.asp?topic_id=211915

mais avec tout le contenu de l'écran, alors que ma fenêtre n'en occupe qu'une petite partie et que le contenu d'elle seule m'intéresse

merci de vos conseils

l'approche actuelle voudrait que tu passes par un pixel shader; tu recuperes le backbuffer que tu passes en parametres a un shader en tant que texture - ton shader lit dans la texture pour calculer la couleur finale de chaque pixel.
A noter que les operations de lecture dans les textures sont relativement couteuses - pour des "petits" noyaux de convolution, ca va, mais si tu montes en dimension de kernel, les performances s'effondrent. Il faut alors "tricher" et oublier la theorie pure de la convolution pour faire une simulation moins couteuse qui donne un resultat proche de celui souhaite (par ex. "eclater" le kernel, et faire de l'interpolation).

pour la lourdeur des calculs, tkt, mon pc a l'habitude

par contre, les shaders, j'ai jamais fait, c'est compliqué à mettre en place?

si ton appli a pour but le temps reel, il te faudra forcement prendre en considerations les limitations techniques des cartes graphiques actuelles. Meme avec du multi-GPU des dernieres 295, tu peux mettre la machine a plat avec simplement une grosse resolution (vu que le cout du pixel shader s'applique a chaque pixel a rendre) et une grosse convolution. Un algo qui tourne tres bien sur un CPU peut etre "minable" une fois porte en version "shader" - non pas a cause de la logique, mais a cause du cout de certaines operations materielles (lecture dans les textures, transfert de donnees memoires, etc. D'autant plus que tout ce qui est traitement du signal se vectorise tres bien avec les archi CPU actuelle, ce qui n'est pas encore le cas avec les GPU).
Bref, le jeux actuels font gros usage de FSE (full-screen effects), et si l'approche theorique reste valide, l'implementation est loin d'etre "ideale" d'un point de vue modelisation, et on a beaucoup recours a des simplifications et astuces pour conserver des performances correctes.

Sinon, pour les shaders, c'est relativement simple, mais il faut bien comprendre le principe ; je te recommande des suivre les tutorials fournis avec les SDK DirectX, ils sont tres bien fait, et devrait tedonner tous les elements dont tu as besoin pour realiser ce que tu souhaites. (il doit y avoir des exemples de high-dynamic range rendering -HDR-, pre-computed radiance tranfert (PRT) ou image based lighting (IBL) )

oui, je regarderai les tutos, merci

mais si tu dis que le cpu pourrait éventuellement mieux s'en sortir, ne vaudrait-il pas mieux simplement trouver un moyen d'accéder aux données du front buffer? après, a la limite je code une fonction capable de récupérer et modifier la couleur d'un pixel et je bricole une librairie graphique en vitesse

note que tu n'accedes jamais au front buffer directement - tu peux recuperer une copie pour travailler dessus, acceder a un des backbuffers de la swap chain, etc.

tu peux faire un surface lock sur ton backbuffer, et lire les pixels directement, mais la combinaison pour recuperer + lire + ecrire + metter a jour la surface sera plus couteuse

tu as l'air de bien t'y connaitre, c'est quoi la swap chaine, exactement? je sais que c'est un des paramètres de la fonction GetFrontBuffer des IDirect3DDevice9, mais pas moyen de trouver de quoi il s'agit sur la msdn

la swap chain, c'est l'ensemble des surfaces qui alternent pour devenir tour a tour pour devenir "front-buffer", et definir l'affichage en cours.

Au minimum, tu en as 2, un front-buffer et un back-buffer ; elles alternent a chaque image, pour "presenter" le visuel a l'utilisateur, pendant que le programme dessine dans celle qui n'est pas affichee. Dans le passe, on pouvoit n'avoir qu'une seule surface, mais cela presente beaucoup d'invenients, et on presentait cette "nouvelle" approche sous le nom de "double-buffering" (qui permet notamment de synchroniser la presentation des surfaces avec le refresh rate de l'ecran, et eliminer tout effet de "tearing").
Maintenant, on fait aussi du triple-buffering, voire plus, et on utilise de nombreuses surfaces off-screen pour la creation d'effets complexes.

essaye ici pour les specs de l'API qui traite des surfaces en D3D9

http://msdn.microsoft.com/en-gb/library/bb219683(VS.85).aspx

je jetterai un oeil, merci beaucoup