Discussion :

[NeZoNeR]

Nouvelle info:

J'ai remarqué en fait lorsque j'utilise D3DXSaveSurfaceToFile il y a un comportement assez étrange.
Dès que je lance l'application et que je vais voir le .BMP qui est généré, si je redimensionne par exemple la fenêtre dans l'écran 2, je vais voir les modifs en "temps réel" et le deuxième écran va bien être pris en compte.
Dès que j'arrete de toucher au deuxième écran et qu'il y a une image fixe (en général c'est VisualStudio qui est ouvert), peut importe ce que je fais par la suite, l'image du deuxieme écran est bloquée et n'est plus jamais mis à jour.

En gros:
- si l'écran est animé et que des évènements tels que le redimensionnement de fenêtre/déplacement d'un dossier...l'écran fonctionne très bien, je récupère chaque frame différente dans le .bmp
- si je ne bouge plus à rien, l'écran reste figé et l'image n'est plus mise à jour...

J'espère que tu as compris mon soucis, je ne sais pas si c'est clair...

Merci.

Dylan

[moldavi]

Bonjour.

Ce que je ne comprends pas, c'est en quoi un memcpy de pBits vers pData puisse corrompre la texture ?

Pour comprendre, il faudrait analyser le contenu de la mémoire du programme à l'instant T. Si un memcpy déborde, il peut corrompre des données mais sans planter le programme (du moins en mode debug).

- Tu n'utilises plus que des textures dans le programme ? Qu'en est-il des surfaces ?
- Tu penses qu'il est plus adapté d'utiliser des textures que des surfaces dans ce genre de situation ?

Il n'y a pas de règle en ce qui concerne l'utilisation de texture/surface. Je n'ai pas expérimenté plus que cela les avantages/inconvénients, et j'utilise les deux.

- Quel est le but de cette ligne ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

uiPitchIn = lrIn.Pitch - ((INT)(desc.Width * 4.0f));

Il faut lire la MSDN : http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

so it is not safe to assume that pitch is just the width multiplied by the number of bytes per pixel.

Selon les cartes graphiques et autre joyeuseté de la programmation DirectX, le pitch est important à comprendre, et donc à gérer.

Dans la boucle, le pointeur est incrémenté. Donc à la fin du "Width", il reste peut-être du Pitch. Je le précalcule avec uiPitchIn. Certes sur ma CG et avec une texture au format A8R8G8B8, "lrIn.Pitch" sera toujours de "desc.Width * 4", mais rien n'assure que ce sera toujours vrai, sur d'autres configurations.

[moldavi]

Bonjour.

Nouvelle info:

J'ai remarqué en fait lorsque j'utilise D3DXSaveSurfaceToFile il y a un comportement assez étrange.
Dès que je lance l'application et que je vais voir le .BMP qui est généré, si je redimensionne par exemple la fenêtre dans l'écran 2, je vais voir les modifs en "temps réel" et le deuxième écran va bien être pris en compte.
Dès que j'arrete de toucher au deuxième écran et qu'il y a une image fixe (en général c'est VisualStudio qui est ouvert), peut importe ce que je fais par la suite, l'image du deuxieme écran est bloquée et n'est plus jamais mis à jour.

En gros:
- si l'écran est animé et que des évènements tels que le redimensionnement de fenêtre/déplacement d'un dossier...l'écran fonctionne très bien, je récupère chaque frame différente dans le .bmp
- si je ne bouge plus à rien, l'écran reste figé et l'image n'est plus mise à jour...

J'espère que tu as compris mon soucis, je ne sais pas si c'est clair...

Merci.

Dylan

Que l'écran reste figé cela me paraît normal, puisqu'il ne se passe rien...

Que l'image ne soit pas mise à à jour est un mystère que je ne peux pas résoudre ici, sans un code source minimal qui reproduise le problème.

[NeZoNeR]

Bonjour.

Pour comprendre, il faudrait analyser le contenu de la mémoire du programme à l'instant T. Si un memcpy déborde, il peut corrompre des données mais sans planter le programme (du moins en mode debug).

Le soucis c'est que même sans le memcpy j'ai ce comportement la. J'ai remarqué ça en ne laissant que le GetFrontBufferData et enregister le contenu de la surface dans un .BMP.

Concernant le point ou l'écran reste figé, je voulais dire par la que si dès le début de l'application je bouge des fenêtres dans le second écran, j'ai bien le bitmap qui est mis à jour. Si je ne fais rien pendant 5 secondes et qu'après ce laps de temps je déplace des fenêtres, le fichier n'est pas mis à jour.

Je fais quelques recherches sur le sujet de mon côté et lorsque j'ai plus d'éléments je reviendrais vers toi.

Merci pour ton aide