Lecture et écriture dans une texture : correct ou non ?

Salut,

J'ai un petit soucis, cette fois-ci pas de résultat, mais de méthode.

Je souhaite avoir accès aux données de textures chargées/créées en mémoire vidéo, d'une part pour les lire, d'autre part pour les modifier.

J'utilise pour cela le LockRect de l'interface IDirect3DTexture9 qui me permet de récupérer un pointeur (void* pBits) vers les données de la texture.

Une fois ce pointeur récupéré, je parviens sans bug à effectuer toute sorte d'opérations sur la texture ou à partir de celle-ci, lecture, édition, enregistrement dans un fichier, etc...
Là ou je me pose une question, c'est que avec ou sans le LockRect, une fois que j'ai récupéré le pointeur, je peux effectuer des opérations sur la texture sans que ce soit plus lent ou que ça plante. Histoire de m'embrouiller un peu plus, j'ai essayé le LockRect en ReadOnly ou sans aucun flag de mode de vérouillage, et je peux toujours effectuer toute sorte d'opérations.

Donc, quelle est la méthode "conventionnelle" pour pouvoir lire et écrire des données dans une texture ? La méthode que j'utilise est-elle correcte ou non ?

Tant qu'à faire, je souhaiterais avoir une méthode aussi bonne que le résultat...

(hop, tag parce que ça m'interesse aussi)

Tout dépend comment la texture a été créé, si c'est le pool managed, tu peux faire tout ce que tu veux avec la texture lire, écrire. En fait le runtime va te renvoyer le pointeur vers la copie qu'il maintient en mémoire système et notifier le driver si tu l'as verrouillé en écriture (pour mettre à jour la copie du driver). Cette mise à jour va être plus ou moins lente suivant la taille de la texture et la fréquence des modifications (et le type de système sur lequel ça tourne).

Si c'est le pool default, tu ne peux locker que les textures créées avec le flag "USAGE_DYNAMIC" (il faut que le device exporte la capacité d'avoir des textures dynamiques), et tu ne peux que écrire (pas lire, y compris les "read/modify/write"). Pour lire le résultat d'un rendu préalable, il faut utiliser GetRenderTargetData et non pas lockrect.

LeGreg

Merci pour la réponse :)

Dans mon cas, j'utilise Pool Managed lors de la création de la texture.

Par rapport aux LockRect, est-il nécessaire que je suive à chaque lecture/écriture de données la procédure : LockRect - Opérations - UnlockRect, sachant qu'une fois que j'ai récupéré le pointeur vers les données de la texture, je peux agir dessus depuis n'importe quel endroit du code, avec ou sans le LockRect ?

la mise à jour ne sera effective qu'au moment du unlock, et donc si c'est utilisé dans un rendu, il faut appeler unlock au moins une fois avant le draw call pour que le runtime ait l'opportunité de mettre à jour la copie du driver.

LeGreg

8O Curieux... Même sans passer par le UnlockRect, la mise à jour a quand même lieu dans mon programme d'essai. Bon, je vais imaginer qu'elle n'a pas lieu et utiliser Lock + Unlock dans les règles de l'art ^^

Je devrais pouvoir me débrouiller à présent, encore merci ;)