IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

DirectX Discussion :

GetFrontBufferData et Ecran 16 bits


Sujet :

DirectX

  1. #21
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : décembre 2012
    Messages : 13
    Points : 2
    Points
    2
    Par défaut
    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

  2. #22
    Membre extrêmement actif

    Homme Profil pro
    Ingénieur test de performance
    Inscrit en
    décembre 2003
    Messages
    1 940
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur test de performance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 940
    Points : 2 573
    Points
    2 573
    Par défaut
    Bonjour.

    Citation Envoyé par NeZoNeR Voir le message
    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).


    Citation Envoyé par NeZoNeR Voir le message
    - 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.

    Citation Envoyé par NeZoNeR Voir le message

    - 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.

  3. #23
    Membre extrêmement actif

    Homme Profil pro
    Ingénieur test de performance
    Inscrit en
    décembre 2003
    Messages
    1 940
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur test de performance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 940
    Points : 2 573
    Points
    2 573
    Par défaut
    Bonjour.

    Citation Envoyé par NeZoNeR Voir le message
    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.

  4. #24
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : décembre 2012
    Messages : 13
    Points : 2
    Points
    2
    Par défaut
    Citation Envoyé par moldavi Voir le message
    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

Discussions similaires

  1. Ecran bleu Windows 7 64 bits
    Par alex_m94 dans le forum Windows 7
    Réponses: 71
    Dernier message: 06/07/2010, 16h48
  2. Ecran figé 64 Bits
    Par pierrei dans le forum Windows 7
    Réponses: 3
    Dernier message: 21/02/2010, 12h37
  3. Cherche l'algo crc 16 bits
    Par icepower dans le forum Algorithmes et structures de données
    Réponses: 2
    Dernier message: 21/08/2002, 14h27
  4. [TP]lire une ligne de l'ecran et la stocker dans une chaine
    Par Bleuarff dans le forum Turbo Pascal
    Réponses: 26
    Dernier message: 02/07/2002, 11h08
  5. Lire 1 bit d'un fichier en C
    Par Anonymous dans le forum C
    Réponses: 3
    Dernier message: 23/05/2002, 19h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo