Bienvenue, Invité. Merci de vous connecter ou de vous inscrire.
Avez-vous perdu votre e-mail d'activation ?

Auteur Sujet: Problème avec les sf::Texture  (Lu 5736 fois)

0 Membres et 1 Invité sur ce sujet

Crone123

  • Full Member
  • ***
  • Messages: 141
    • Voir le profil
Problème avec les sf::Texture
« le: Mars 03, 2013, 02:32:55 am »
Bonjour,
Dans la SFML 2.0 RC j'ai eu un problème avec les sf::Textures sur ma carte ATI.
J'avais déjà parlé d'un problème avec les sf::ConvexShape.

J'ai maintenant la raison de "pourquoi ça fonctionnait sur la 1.6 et ne fonctionne plus sur la 2.0 !"
Les sf::Shape de la 1.6 étaient fait uniquement par des points et des couleurs. Les sf::ConvexShape de la 2.0 utilisent des sf::Texture.


A partir d'ici vous pouvez quasiment zapper le message et passer au suivant, je me rends compte que j'ai dit un truc parfaitement inutile et que le message suivant corrige, en apportant un code minimal. (Vous pouvez toujours télécharger la comparaison de rendu d'image entre les 2 cartes de ce post pour avoir une idée plus précise du bug)

Dans je ne sais quelle condition, je n'arrive pas a utiliser correctement les sf::Texture sur ma carte ATI.

J'ai testé dans une fenêtre SFML seule, ça a l'air de marcher.
Dans un QSFMLCanvas ça a l'air de marcher (sauf que pour la version nightly fait rajouter XInitThread dans le main.cpp sinon ça le programme crash).

Moi je suis dans le cas où justement j'utilise un QSFMLCanvas.

J'ai un QWidget de base, qui contient un menu (Type Fichier, Édition, etc..) et j'ai juste en dessous un rendu SFML. (Si le QWidget ne contient rien, a priori tout fonctionne dans la SFML)

Maintenant, j'ai 2 jeux différents, qui utilisent le même système de fenêtre avec une menu sur le QWidget, et le rendu SFML en dessous.
Sur ces 2 jeux, j'ai le problème suivant: Les sf::Texture ont des bugs.

Dans le premier jeu, le problème a l'air de se limiter aux textures générées à partir de sf::Image, et donc mes sf::ConvexShape. C'est comme ça que je génère mes dégradés, et a priori il y a un conflit quelque part avec Qt puisque les textures sont bugguées.

Dans un second jeu, toutes les sf::Texture que je charge sur la carte ATI sont buguées. (Je n'ai pas de problèmes sur la carte Nvidia, les pilotes Nvidia doivent s'occuper eux même du problème)

J'ai donc modifié le code du jeu, et essayé la chose suivante: Charger une sf::Image. La sauvegarder sur le disque dur. La convertir en sf::Texture, et sauvegarder la sf::Texture sur le disque dur.

Résultat: Sur la carte Nvidia, tout fonctionne correctement en jeu, et les images de sorties sont intactes.
Sur la carte ATI, le jeu est entièrement buggué, les images provenant des sf::Images sont intactes, et les images provenant des sf::Textures sont bugguées.

Je vous ai fait une archive contenant les images sauvées sur le disque dur pour chaque carte graphiques.
Elles sont de tailles différentes, et donc ce n'est pas un type d'image qui bug, c'est bien toutes les textures.

L'archive: http://s2.smglive.org/SFML/Test.7z
Les images en _Img sont les sf::Image qui ont été chargé depuis le disque dur et sauvés directement.
Les images en _Tex sont les sf::Texture qui ont été sauvées sur le disque dur.
→ Charger une sf::Texture depuis le disque dur, ou charger une sf::Image et la convertir en sf::Texture ensuite fait le même résultat.

Je pense a un bug mémoire où quelque chose du genre parce que les _Tex de la carte ATI changent à chaque fois de tête.

ici on reconnais encore par endroit des fragments de l'image originale.
Si j'avais lancé un autre jeu avant (SFML ou pas) j'aurais eu des fragments de cet autre jeu.
Si j'avais tapé dans mon shell de GNOME3 avant, j'aurais eu des fragments de mes raccourcis de mon shell GNOME3.

J'ai fait un test du programme donc, depuis l'ordi avec la carte ATI, qui lance le jeu par SSH sur un ordi avec une carte Nvidia. Résultat: Le jeu s'affiche correctement sur le client avec la carte ATI. (avec quelques lenteurs dues au SSH)

Le problème n'est donc pas de l'affichage, mais du calcul des textures par la SFML.

Je dois faire une présentation pour mon TPE (pour mon bac), et j'ai codé exprès un logiciel pour faire de meilleures diapo qu'un simple PowerPoint, et il utilise la SFML avec Qt.

Je l'ai développé sur ma tour avec carte Nvidia, et surprise pour ma carte ATI....
Au début, je pensais que c'était uniquement ma carte qui bugguait avec les pilotes Linux. (Proprio, et je les ai mis a jour en version 13.1 hier j'ai la même chose).

Ma carte est une Mobility Radeon HD 4470.
Et en fait non, j'ai testé sur 7 ordis avec tous une carte ATI différente, et j'ai le même résultat partout.
J'ai testé sur:
Ubuntu 12.04 LTS
Ubuntu 12.10
Windows Xp
Windows 7
Et j'ai testé généralement un Windows et un Linux pour chaque ordi.

J'ai pareil, ou presque. Sur Linux, j'ai une image totalement bugguée qui s'affiche. Sur Windows, je n'ai pas d'image du tout, j'ai "rien" qui s'affiche.

En dehors des sf::Texture, tous les autres objets graphiques fonctionnent correctement.

→ Je le dit au passage, malgré que j'ai mis XInitThreads dans le main.cpp sans quoi le jeu crash, il arrive qu'il crash encore de temps en temps avec ça. Exemple, le second jeu que j'ai voulu testé, je n'ai pas pu le démarrer sur le serveur SSH a cause de cette erreur, tant qu'il n'y a que l'interface Qt tout va bien, mais dès que le QSFMLCanvas démarre j'ai cette erreur:
Xlib: sequence lost (0x10053 > 0x56) in reply type 0x0!
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
SMG_RPG: ../../src/xcb_io.c :178 : dequeue_pending_request:  l'assertion « !xcb_xlib_unknown_req_in_deq » a échoué.
./Start.sh : ligne 3 :  3546 Abandon                 (core dumped) ./SMG_RPG
Erreur que j'avais de temps en temps avec la SFML 2.0 rc (pas nightly) et que j'ai aussi sur carte Nvidia.

Donc je pense que le "fameux bug" graphique est du a un problème d'intégration entre la SFML et Qt. (Ils doivent s’emmêler les pinceaux ou le genre..)

Voilà, je termine de reproduire le bug mais actuellement la seule différence entre la version qui marche et celle qui bug c'est l'intégration avec Qt.
→ Sur la version Windows par contre, j'avais carrément des crash graphiques et impossible de démarrer la SFML en tant que QSFMLCanvas dans Qt, donc mes tests sur Windows ont été en tant que QSFMLCanvas mais en dehors d'un autre QWidget.

Faudrait donc creuser de ce coté là. Le QSFMLCanva utilisé est celui de la 1.6 modifié pour appeler les fonctions de la 2.0 (changement de casse des noms de fonction) a partir de là j'espère que vous pourrez m'aider, je peux faire des tests, modifier les QSFMLCanva et au besoin aller directement modifier dans les fichiers de la SFML (et recompiler) pour trouver d'où ça viens :)

Je suis là toute la semaine (vacances solaires) et j'espère qu'on aura trouvé une solution pour le Lundi 11, si d'ici là c'est pas trouvé je m'arrangerait autrement bien sûr, mais avoir des jeux qui marchent sur carte ATI ça serait nickel.

→ Si vous connaissez "M.A.R.S a ridiculous shooter" qui est un jeu développé avec la SFML 2.0. Je l'ai testé sur la carte ATI il y a 5min pour voir, et il ne bug absolument pas. Il utilise uniquement la SFML sans Qt. Donc le bug doit vraiment provenir de l'intégration de la SFML dans Qt.

Merci :)

PS: Désolé pour la taille du post, je ne sais pas trop faire court pour expliquer un truc.
« Modifié: Mars 03, 2013, 03:14:17 am par Crone123 »

Crone123

  • Full Member
  • ***
  • Messages: 141
    • Voir le profil
Re : Problème avec les sf::Texture
« Réponse #1 le: Mars 03, 2013, 03:10:39 am »
J'ai continué mes tests, et finalement Qt on l'oublie.

J'ai réussi a reproduire le bug dans un projet 100% SFML, ça tiens sur 39 lignes de code, 1 seul fichier. (main.cpp)

Donc, ma texture de fond s'est transformée en...fond de "M.A.R.S a ridiculous shooter" que j'ai testé 5min avant. Enfin, le fond était bien défoncé au passage, il était buggué quoi.

Ce bug se produit si la sf::Texture est chargée depuis un sf::Thread.
Toutes mes textures sont chargées depuis un thread. J'aurais du y penser, mais oui, ça crée un bug.

Pour la même fenêtre, Qt ou pas Qt, si y a un Thread, ça bug, si y en a pas, ça ne bug pas.
Et ça bug uniquement sur les cartes ATI, sur les cartes Nvidia ça ne bug pas.

J'ai donc déjà une solution temporaire pour que ça fonctionne sur ATI: Ne pas utiliser de thread au chargement.
Facile a dire pour un de mes projets, difficile a faire pour un second, car le nombre de ressources a charger est trop important pour se passer d'un thread. (sinon l'utilisateur est devant un jeu Freezé pendant 30s)

Voici le code source qui reproduit le bug: http://s2.smglive.org/SFML/main.cpp
Voilà, a vous de voir si le bug viens de moi ou de la SFML (maintenant que j'ai enfin réussi a reproduire le bug :) ), si vous voyez d'où ça viens expliquez moi comment le corriger comme ça je pourrais avoir un Thread qui charge correctement les sf::Texture sur les cartes ATI.

Merci :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Problème avec les sf::Texture
« Réponse #2 le: Mars 03, 2013, 08:53:56 am »
Essaye deux choses :

- glFlush() après l'appel à loadFromFile (inclue et lie OpenGL)
- ne pas utiliser la texture dans le thread principal tant qu'elle n'est pas chargée
Laurent Gomila - SFML developer

Crone123

  • Full Member
  • ***
  • Messages: 141
    • Voir le profil
Re : Problème avec les sf::Texture
« Réponse #3 le: Mars 03, 2013, 03:10:29 pm »
Donc, contrairement a l'exemple, je n'utilise pas les sf::Texture en même temps que je les charge dans mes jeux.


Dans tous les cas que j'ai essayé , ça fonctionne sur la carte Nvidia.

Par contre:
glFlush() seul fait crasher le programme sur la carte ATI.
glFlush() accompagné de XInitThreads() en première ligne dans main() fonctionne correctement sur la carte ATI.

Je vais essayer ça dans mon autre projet plus gros, je vous tiens au courant.

Y a t-il moyen que ça soit rajouté en correctif dans la SFML? (pour ne pas avoir besoin de s'en occuper sois même)

Au fait, quel est l'équivalent de XInitThreads() sur Windows? J'ai le programme qui crashe systématiquement sur Windows dans un module graphique Qt a cause de ça....

Merci :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Problème avec les sf::Texture
« Réponse #4 le: Mars 03, 2013, 04:10:49 pm »
Citer
Y a t-il moyen que ça soit rajouté en correctif dans la SFML?
Ca doit effectivement être corrigé dans SFML, mais c'est assez problématique, je ne peux pas simplement ajouter des glFlush() comme ça (ça tuerait complètement les performances, ça doit être utilisé avec parcimonie).

Citer
Au fait, quel est l'équivalent de XInitThreads() sur Windows?
Il n'y en a pas sous Windows, ton crash doit être causé par autre chose.
Laurent Gomila - SFML developer

Crone123

  • Full Member
  • ***
  • Messages: 141
    • Voir le profil
Re : Problème avec les sf::Texture
« Réponse #5 le: Mars 03, 2013, 04:46:22 pm »
Citer
Il n'y en a pas sous Windows, ton crash doit être causé par autre chose.
OK, je regarderais ça :)
Citer
Ca doit effectivement être corrigé dans SFML, mais c'est assez problématique, je ne peux pas simplement ajouter des glFlush() comme ça (ça tuerait complètement les performances, ça doit être utilisé avec parcimonie).
Vu que c'est a utiliser dans loadFromFile, qui est une fonction que l'on utilise uniquement pour charger des Textures que l'on utilise normalement pas a chaque rafraîchissement ça peut passer.

Par contre, dans sf::Texture::update() par exemple ça peut être un problème. (dans mon cas non, mais dans d'autres cas oui..)

Peut être qu'il y a une autre fonction qui ne boufferait pas les performances mais qui feraient le même effet?
Merci :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Problème avec les sf::Texture
« Réponse #6 le: Mars 03, 2013, 06:15:50 pm »
Oui, ça poserait problèmes dans d'autres fonctions que loadFromFile.

Et non, il n'y a pas d'autre fonction qui fasse la même chose en plus performant -- c'est justement parce que ça fait ce que ça fait que c'est problématique ;)
Laurent Gomila - SFML developer

Crone123

  • Full Member
  • ***
  • Messages: 141
    • Voir le profil
Re : Problème avec les sf::Texture
« Réponse #7 le: Mars 03, 2013, 07:09:49 pm »
Normalement c'est au driver de s'occuper de ça, sauf.... que c'est un driver ATI....
En fait, sinon faudrait un booléen a rajouter en paramètre qui a true le ferait, a false (default) ne le ferait pas...
Ou bien simplement indiquer dans la doc que l'intégration avec Qt pour fonctionner correctement sous Linux requiert d'utiliser XInitThreads dans le main et que les textures chargées depuis un Thread risquent de poser des problèmes sur les cartes ATI et donc qu'il est conseillé de rajouter un glFlush() après.

Mais bon, si ça pouvait être intégré ça serait mieux :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Problème avec les sf::Texture
« Réponse #8 le: Mars 03, 2013, 07:20:15 pm »
Citer
Normalement c'est au driver de s'occuper de ça
Non, c'est à l'utilisateur final de le faire. C'est pour ça que SFML ne peut pas le faire, c'est vraiment trop haut niveau, c'est un choix qui ne peut pas être automatisé.
Laurent Gomila - SFML developer

Crone123

  • Full Member
  • ***
  • Messages: 141
    • Voir le profil
Re : Problème avec les sf::Texture
« Réponse #9 le: Mars 03, 2013, 07:23:41 pm »
Donc la petite note dans la doc reste la seule solution?

Au passage, où trouve t-on la doc des version nightly?
Je demande parce que la version nightly est différente de la version 2.0 rc
Merci :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Problème avec les sf::Texture
« Réponse #10 le: Mars 03, 2013, 07:33:16 pm »
Citer
Donc la petite note dans la doc reste la seule solution?
Non. Je peux peut-être trouver un moyen de détecter que je suis dans un cas où il faut l'appeler, et au pire je peux toujours l'encapsuler dans une fonction, ce qui évitera au moins que l'utilisateur ait à inclure et lier OpenGL en plus de SFML, juste pour ça.

Citer
Au passage, où trouve t-on la doc des version nightly?
Il faut la compiler. cf. le tuto de compilation de SFML.
Laurent Gomila - SFML developer

Crone123

  • Full Member
  • ***
  • Messages: 141
    • Voir le profil
Re : Problème avec les sf::Texture
« Réponse #11 le: Mars 03, 2013, 08:01:41 pm »
Citer
Il faut la compiler. cf. le tuto de compilation de SFML.
OK je vais voir ça :)
Citer
Non. Je peux peut-être trouver un moyen de détecter que je suis dans un cas où il faut l'appeler, et au pire je peux toujours l'encapsuler dans une fonction, ce qui évitera au moins que l'utilisateur ait à inclure et lier OpenGL en plus de SFML, juste pour ça.
Tenez moi au courant alors :)
Merci :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Problème avec les sf::Texture
« Réponse #12 le: Mars 04, 2013, 09:02:02 am »
Citer
Tenez moi au courant alors
C'est pas prévu pour tout de suite hein ;D
Laurent Gomila - SFML developer

Crone123

  • Full Member
  • ***
  • Messages: 141
    • Voir le profil
Re : Problème avec les sf::Texture
« Réponse #13 le: Mars 04, 2013, 12:33:26 pm »
Oui, justement :)

Lolilolight

  • Hero Member
  • *****
  • Messages: 1232
    • Voir le profil
Re : Problème avec les sf::Texture
« Réponse #14 le: Mars 04, 2013, 01:34:53 pm »
Salut, j'ai une carte ATI également, il faudrait que j'essaye une fois de charger une texture à partir d'un thread pour voir si ça marche.