bon le titre cété pour attire le plus de monde possible.
 
plus sérieusement voici ma question:
 
N'existe-t-il pas un moyen d'avoir un accès rapide en lecture sur un surface en mémoire vidéo ????
Que ce soit en OpenGL ou En DirectDraw/Direct3D, je ne trouve aucun moyen pour lire des données en mémoire vidéo rapidemment.
 
En fait le problème est le suivant:
je fais un rendu 3D sur une surface (obligatoirement en mémoire vidéo à moins de le faire en soft mais c bien trop lent) et je veux ensuite me servir de cette surface comme d'une texture que je pourrais appliquer sur un polygones pour le prochain rendu. Je sais que c possible à faire avec une vitesse correcte car certains jeux le font (bon j'en ai pas en tête mais ça existe, je l'ai déjà vu). Moi quand je blit ma surface back (sur laquelle j'effectue mon rendu 3D) dans ma texture, c affreusement lent, car la surface back est en mémoire vidéo, et l'accès en lecture en mémoire vidéo est trop trop lent. J'ai essayé l'OpenGL (en me servant d'une fonction pour lire des blocs de pixels dans le backbuffer) aussi mais cété pas terrible non plus et c pas aussi pratique que le DirectX (pas de blit).
 
Merci très beaucoup d'avance car je vais craquer  !

[edtdd]--Message édité par ZZZzzz--[/edtdd]

Ni l'un ne l'autre ne propose de lecture réellement rapide de la mémoire vidéo.
Ce doit être une limitation hadware d'ailleurs.

beuh..  
remarque j'en avais peur.. mais alors comment faire ce type d'effet ? car certains jeux le font, j'en suis sûr..

jviens de penser à un truc ... on peut accéder en "lecture" sur une surface vidéo rapidemment. La preuve en est quand je blite ma surface back (en fait elle est juste défini comme offscreen et supportant un rendu 3D) contenant le rendu 3D (en mémoire vidéo) sur la surface primary c rapide. Or il y a forcément lecture de la surface back pour pouvoir la copier dans la surface primary. c pourquoi je comprends pas pourquoi ça foire: en effet quand je blitte ma surface "back" vers la primary: c rapide ! quand je blitte cette même surface sur la surface texture (ma texture est contenu dans une surface crée aussi en mémoire vidéo) c lent !! et pourtant le fait d'écrire dans la surface texture n'est pas une opération lente (je le sais car quand j'écris directos dedans comme un porc ça reste rapide tant qu'il n'y a pas ce fameux blit)... alors ?? pourquoi l'un des blits est plus rapide que l'autre ?? comprends pas ...

[edtdd]--Message édité par ZZZzzz--[/edtdd]

bon j'attends toujours la réponse. J'espère que ce forum va bien me servir au moins une fois. C la troisième fois que je poste un topic dans celui-ci et pour les 2 premiers, personne n'avait pû me répondre .
Sinon ptêt que quelqu'un connait un forum où yaurai des personnes suceptibles de pouvoir me répondre ??
 
Merci d'avance !

http://discuss.microsoft.com/archives/DIRECTXDEV.html
 
si l'accès est lent c'est simplement parce que ... l'accès à cette mémoire est lent faut faire transiter les pixels de la carte vers la mem, ça ramouille.
 
et surtout, ça pête le pipeline de rendu : quand tu fais un drawprimitive(), le rendu n'est pas éxécuté tout de suite. par ex pour un drawprimitive à partir d'un buffer mémoire, dx copie le buffer et te rend la main. tout ça marche joliment en asynchrone. et donc si tu veux lire une surface, dx doit attendre que tous les appels bufferés utilisant cette surface aient été éxécutés. en gros : ça rame.
 
normalement aucun jeu ne fait ça. rendre un bout de scène pour s'en servir comme texture, oui, ça passe très bien avec un SetRenderTarget(). et pour les cartes qui ne supportent pas cette fonctionnalité, le jeu fait généralement sa popote en software (l'exemple qui me vient à l'esprit étant les ombres dans vampire).

merci pour ta réponse youdon'tcare (et merci pour le lien). Je vais essayer le setrendertarget, mais j'ai peur que de rendre dans une surface texture pose problème. Pourtant je suis sûr d'avoir vu des jeux utilisant ce genre d'effet (on voit le jeu rendu en plus petit dans un écran ou ce genre de chose). Par contre cela ne réponds pas à ma question concernant le fait qu'un blit de back->primary est plus rapide que back->texture en considérant le fait que d'écrire seulement dans la texture (sans lire la back) reste rapide ... quelqu'un a une idée ??

je sais pas ce que t'end par blit.
Mais bon, d'après ce que j'ai compris lorsque tu copies une image videos pour faire une texture, tu récupère les données en mémoir videos pour les passer en mémoire vive puis tu les repasse en mémoir video lors de la création de la texture, tout ca en devant vider le pipline, pour récupérer le rendu.
En direct3D je crois que c'est possible de ne pas devoir passer par l'étape de la mémoir vive de l'ordi et faire le traitement mémoire video-mémoire video.  
back vers primary est rapide puisque c'est mémoire video, vers mémoire video (sans passer par l'agp) tandis que back-> texture passe par le bus AGP.

qq liens pour le render to texture :  
 
http://cedar.intel.com/cgi-bin/ids [...] _EDITORIAL
 
http://partners.nvidia.com/marketi [...] D700058D92

[edtdd]--Message édité par youdontcare--[/edtdd]

hercule> justement dans mon cas je ne passe pas par la mémoire vive (ma texture reste en mémoire vidéo) c pourquoi je ne comprends pas que ce soit si long. un blit c en gros une copie mémoire mais réalisé en hard si possible. ça peut gérer le strech si besoin...
 
Youdon'tcare> je vais regarder tes liens. En attendant j'ai tout essayé avec le SetRenderTarget et apparement ya pas moyen de rendre directement dans une texture (j'ai essayé avec de Textures: une "back" et une "primary" pour éviter les concurrences d'accès). Ce qui me surprend c qu'il n'affiche pas de messages d'erreurs...

j'oubliais, merci encore à vous deux !

j'ai regardé le premier lien. à priori seule la méthode A m'intéresse ( c celle que j'essaie actuellement d'implémenter) mais elle ne fonctionne pas sur toutes les cartes. C d'autant plus bizarre que la démo (second lien) correspond exactement à ce que je veux faire (et ça fonctionne bien sur ma carte), donc je devrai pouvoir yarriver avec ça ! par contre pour l'instant je vois pas la différence avec mon code (dans leur implémentation), j'ai dû oublier quelque chose dans l'initialisation ou un truc de ce genre.. j'ai pas encore tout analyser leur code, je pige pa tout.. je débute à peine en 3D.

j'ai regardé les deux programmes sources des deux démos (nvidia et intel) et franchement je vois pas ce qui cloche ... j'initialise ma surface avec les params D3DDEVICE et TEXTURE (ça passe), ensuite je fais un SetRenderTarget sur ma surface Texture et là encore ça passe (pas de message d'erreur), par contre le rendu ne s'effectue ps dessus (le surafece reste desespérement noire). Même en ne faisant qu'un "ClearTarget" en blanc par exemple, ça marche pas (ça reste noire) ! d'autant plus incompréhensible qu''il n'y a aucune erreur retournée par les fonctions...  
Une idée ?

t'entends quoi par "pas de message d'erreur" ? les fonctions renvoient bien S_OK ?  
 
sinon j'en sais trop rien ... tu peux essayer d'installer les drivers debug pour voir.

j'oubliais, pour que ça marche il faut que le nouveau target ait un zbuffer attaché de même type que l'ancien target. (ie il faut que la texture ait un zbuffer attaché de même type que le viewport).

youdon'tcare> les fonctions retournent tous D3D_OK, et par ailleurs ma surface back de rendu n'a aps de Z-buffer associé, tout comme ma surface texture. Vraiment je comprends pas... mais je vais essayer de décortiquer les sources des démos jusqu'à temps de comprendre pourquoi ça foire dans mon code.

et le bit depht est le même aussi...

up