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

Auteur Sujet: Demande d'infos : sfml 1.6-2.0, ATI et solutions  (Lu 14298 fois)

0 Membres et 1 Invité sur ce sujet

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32498
    • Voir le profil
    • SFML's website
    • E-mail
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #15 le: Juillet 04, 2012, 02:29:24 pm »
Merci pour les détails :)

Citer
Nous héritions des classes sfml principalement pour les interfacer avec nos systèmes de load/save a partir de fichiers / flux
Ce genre de chose se fait très bien en dehors des classes, typiquement avec des fonctions surchargées. D'ailleurs il n'y a pas à aller bien loin pour le constater : pour rendre une classe X compatible avec std::ostream, tu n'as pas besoin de dériver de X, il faut uniquement fournir une surcharge de l'opérateur <<.

Citer
ainsi que pour la gestion du positionnement des objets une fois insérés dans nos "Maps" ( positionnement local par rapport a la map parente pour l'affichage, Global pour la physique et autres... )
Ca je ne commente pas car j'ai du mal à voir ce que ça implique au niveau du code.

Citer
Nous avions aussi besoin de redéfinir les draw pour appeler automatiquement une update dans ce dernier
Ouhlala que c'est moche ça :P
Ne jamais mettre dessin et mise à jour ensemble ! C'est la solution de facilité pour les fainéants dans les codes courts, mais dans un moteur complet, non. D'ailleurs pour éviter ça j'ai mis une autre barrière : la fonction draw est const ;)

Remarque globale : qu'est-ce qui vous empêche d'avoir des classes qui contiennent des sprites/textes/shapes, plutôt que des classes qui en dérivent ? Vous faites vos propres sf::Drawable, avec leur propre interface publique qui colle pile poil à votre moteur, et dedans vous utilisez un sf::Sprite, un sf::Text, etc. Et là vous restez maîtres à 100% de votre design, vous utilisez SFML uniquement comme outil d'implémentation. C'est ça que je défend comme conception avec le design que j'ai choisi pour les classes de SFML.
Laurent Gomila - SFML developer

coco

  • Newbie
  • *
  • Messages: 26
    • Voir le profil
    • Galhmac Game Studio
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #16 le: Juillet 09, 2012, 10:37:33 am »
Salut !

J'ai bien avancé sur le portage, sans que ce soit pour autant fini. J'ai pas trouvé la 2.0rc en recompilable ( j'ai surement mal cherché ), donc j'ai récup un snapshot du dépot. Pour l'instant j'ai modifié la lib en attendant d'avoir le temps de me pencher sur les suggestions que tu nous as fait. Ca nous embêtait un peu de contenir les objets sfml dans nos sprites, car ça nous oblige a faire des accesseurs d'accesseurs pour les données de sfml. C'est tout aussi perturbant de faire un getSprite sur un Sprite...

On essaiera de revoir le design lorsqu'on aura du temps pour ça =)

Sinon j'ai rencontré un autre problème :

En dynamic, J'ai un crash lorsque je quitte le progamme en ayant instancié un objet audio, je pense plus ou moins lié à ce bug (sur Trust ~= XP )

https://github.com/SFML/SFML/issues/30

La static corrige effectivement le problème, mais bon c'est pas l'idéal pour la dynamic. Si j'ai bien compris, ce bug ne sera pas corrigé pour la 2.0 mais la suivante ? C'est pas un peu le même genre de problème que pour l'ATI sur la 1.6 ?

Merci =)

Colin


Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32498
    • Voir le profil
    • SFML's website
    • E-mail
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #17 le: Juillet 09, 2012, 10:40:20 am »
En effet ce sera corrigé pour la 2.1, et en effet c'est le même genre de bug que 1.6/ATI :)
Laurent Gomila - SFML developer

coco

  • Newbie
  • *
  • Messages: 26
    • Voir le profil
    • Galhmac Game Studio
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #18 le: Juillet 09, 2012, 10:57:31 am »
Il "suffirait" donc de faire une fonction init/deinit pour les contextes openAL ?

Sinon pour la 2.1, il y aura des modifs niveau utilisateur par rapport à la 2.0 ? Et tu as une estimation du délai avant qu'elle soit prête ?

Merci pour ces réponses =)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32498
    • Voir le profil
    • SFML's website
    • E-mail
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #19 le: Juillet 09, 2012, 11:10:31 am »
Aucune idée. Je fais les choses l'une après l'autre, et pour l'instant je suis encore dans 2.0 ;)
Laurent Gomila - SFML developer

coco

  • Newbie
  • *
  • Messages: 26
    • Voir le profil
    • Galhmac Game Studio
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #20 le: Juillet 20, 2012, 01:47:11 pm »
Bonjour !

On a finalement réussi tant bien que mal a passer à la 2.0. Le moteur et les jeux tournent, j'ai du revoir certaines parties, mais ça c'est plutôt bien passé dans l'ensemble.

En revanche j'ai trouvé 2 problèmes ( je pense pouvoir fournir un code minimal si besoin )

- Spécifique ATI, apparement :
En parcourant le forum, j'ai cru comprendre qu'il n'y avait plus besoin de déclarer un sf::Context dans les threads pour charger les textures. Sur une nvidia ça fonctionne, par contre sur un pc avec une ATI, une texture chargée dans un thread, puis liée à un sprite lui même dessiné dans le main thread ne s'affiche pas. Déclarer un sf::Context dans le thread corrige le problème.

- Général
C'est peut-être "normal", mais si on associe une texture à un sprite de la façon suivante :
sf::Sprite sprite;
sprite.setTexture(sf::Texture());
 
Ensuite si on le dessine ( avec cette texture "vide" ), puis on change de texture pour une texture "valide", le sprite avec la nouvelle texture ne s'affiche pas a l'écran.

A part cela, j'aurais une petite question sur les sf::Texture. Si j'ai bien compris, elle sont chargées sur la RAM graphique. Que se passe t'il si on essaie de charger une image alors qu'il n'y a plus de RAM graphique ( a moins que ça ne puisse pas arriver ) ?

Merci,
Colin

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32498
    • Voir le profil
    • SFML's website
    • E-mail
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #21 le: Juillet 20, 2012, 04:29:37 pm »
Citer
- Spécifique ATI, apparement :
En parcourant le forum, j'ai cru comprendre qu'il n'y avait plus besoin de déclarer un sf::Context dans les threads pour charger les textures. Sur une nvidia ça fonctionne, par contre sur un pc avec une ATI, une texture chargée dans un thread, puis liée à un sprite lui même dessiné dans le main thread ne s'affiche pas. Déclarer un sf::Context dans le thread corrige le problème.
Je veux bien un code complet minimal, et un peu plus d'infos (OS, ...).

Citer
Ensuite si on le dessine ( avec cette texture "vide" ), puis on change de texture pour une texture "valide", le sprite avec la nouvelle texture ne s'affiche pas a l'écran.
Il faut utiliser le second paramètre de setTexture.

Citer
A part cela, j'aurais une petite question sur les sf::Texture. Si j'ai bien compris, elle sont chargées sur la RAM graphique. Que se passe t'il si on essaie de charger une image alors qu'il n'y a plus de RAM graphique ( a moins que ça ne puisse pas arriver ) ?
Une erreur, j'imagine. Mais mieux vaut ne pas en arriver là, si tu veux mon avis ;)
Laurent Gomila - SFML developer

coco

  • Newbie
  • *
  • Messages: 26
    • Voir le profil
    • Galhmac Game Studio
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #22 le: Juillet 20, 2012, 05:10:29 pm »
1 - J'ai oublié de préciser un peu, désolé ^^
Là, J'ai fait des tests sur Windows 7, avec une ATI et avec une Nvidia. Ca fonctionne bien sur le pc Nvidia et pas sur l'ATI. Je pense que les drivers de l'ATI sont a jour ( de fin juin ).

nb : Je te laisse remplacer l'image chargée par celle de ton choix...

sf::Texture* texture = NULL;

void createTexture()
{
   //sf::Context glContext; //Fonctionne correctement sur ATI si cette ligne est décommentée
   
   texture = new sf::Texture();
   texture->loadFromFile("image.png");//Changer pour une image accessible
}

int _tmain(int argc, _TCHAR* argv[])
{
   sf::RenderWindow window;

   window.create(sf::VideoMode(500,500,32), "test app");

   sf::Thread createThread(createTexture);

   createThread.launch();
   createThread.wait();

        sf::Sprite sprite;
   sprite.setTexture(*texture);

   bool loop = true;
   while ( loop )
   {
      sf::Event sfEvent;
      while (window.pollEvent(sfEvent))
      {
         if (sfEvent.type == sf::Event::Closed )
            loop = false;
      }

      window.clear(sf::Color::Black);
      window.draw(sprite);
      window.display();
   }

   delete texture;
   texture = NULL;

   window.close();
   return 0;
}
 

Si tu as besoin de plus d'informations...

2 - J'avais pas vu ce paramètre... ça peut aider ^^

3 - Je pense aussi que ça va poser problème, d'où ma question. Ce que je voulais dire, c'est est-ce qu'il les chargera en RAM normale si la RAM graphique est pleine ? Parce que sinon selon la capacité de la carte graphique de l'utilisateur, ça risque de poser plein de problèmes... du coup, ça limite beaucoup la quantité d'image utilisables en même temps ( par rapport a la 1.6 ), non ? Parce que là j'ai pas les chiffres exacts, mais sur Exodus on arrivait bien a 900 MO de ram ( dont surement au moins les 2/3 d'images, estimation rapide ). Si on peux compter sur n'importe quel pc un minimum récent pour avoir au moins 2GO de ram software, c'est pas la même pour celle des cartes graphiques...

Je suis loin d'être expert, c'est pour cela que je me renseigne...


Merci =)
« Modifié: Juillet 20, 2012, 06:41:17 pm par coco »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32498
    • Voir le profil
    • SFML's website
    • E-mail
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #23 le: Juillet 20, 2012, 07:38:34 pm »
1- Merci, je regarde ça dès que possible.

3- Le mieux est de tester directement, je ne peux pas te donner une réponse sûre à 100%.
Laurent Gomila - SFML developer

Haze

  • Full Member
  • ***
  • Messages: 201
    • Voir le profil
    • Github Profile
Re : Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #24 le: Juillet 24, 2012, 12:22:04 pm »
Je ne veux pas que les gens dérivent de ces classes car dans 99% des cas leur solution est incorrecte (du point de vue du design). J'essaye de les orienter vers les bons choix, qui est de les utiliser par aggrégation.

Après, on peut bien sûr discuter de chaque cas, et je me ferai un plaisir de revenir sur mes choix si quelqu'un me donne un excellent contre-exemple.
J'ai toujours eu pour habitude de faire hériter mes entitiés graphiques de sf::Sprite dans mes jeux. Je peux ainsi les dessiner directement — target.draw(entity) — et réutiliser les méthodes de sf::Sprite.

Si j'utilise l'aggrégation, je dois :
- soit mettre un getter non constant sur le sprite (crade...)
- soit recoder les méthodes nécessaires et les rediriger vers l'attribut sprite (redondance de code)

Quel intérêt aurais-je à utiliser l'aggrégation plutôt que l'héritage ?

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Messages: 4321
    • Voir le profil
    • E-mail
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #25 le: Juillet 24, 2012, 01:47:31 pm »
Citer
soit recoder les méthodes nécessaires et les rediriger vers l'attribut sprite (redondance de code)
Si tu veux faire ça, il y a un petit truc qui est plus court mais qui revient au même (avec la restriction que ça ne marche uniquement si tu as un seul attribut de type T) :

struct T { void foo(); };

class U1 {
    T myT;
public:
    void foo() { myT.foo(); }
};

class U2 : private T {
public:
    using T::foo;
};

U1 et U2 sont strictement équivalent pour l'utilisateur.

(Je n'ai pas lu toute la discussion, cette technique générale ne s'applique donc pas forcement à ton cas!)
« Modifié: Juillet 24, 2012, 02:13:53 pm par Hiura »
SFML / OS X developer

mccusti

  • Invité
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #26 le: Juillet 24, 2012, 01:59:39 pm »
Avec SFML 2 tu peux hériter de sf::Drawable pour pouvoir écrire target.draw(entity). Tu peux aussi hériter de sf::Transformable pour manipuler ton sprite à ta guise, sf::Sprite héritant lui-même de sf::Transformable. Enfin il reste les méthodes propres au sprite, du type setTexture. Ca fait peu de méthodes, surtout que toutes ne seront pas forcément utiles à la classe que tu écris. Donc ça permet, comme le disait Laurent, de supprimer des méthodes auxquelles l'utilisateur ne doit pas avoir accès. Tu as un très bon exemple ici http://fr.sfml-dev.org/forums/index.php?topic=8148.msg54382#msg54382 où Laurent explique bien mieux les choses que moi.

Haze

  • Full Member
  • ***
  • Messages: 201
    • Voir le profil
    • Github Profile
Re : Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #27 le: Juillet 24, 2012, 02:27:02 pm »
struct T { void foo(); };
class U1 {
    T myT;
public:
    void foo() { myT.foo(); }
};

class U2 : private T {
public:
    using T::foo;
};

U1 et U2 sont strictement équivalent pour l'utilisateur.
Merci ! Je ne connaissais pas cet usage de using. Très pratique pour exposer uniquement certaines méthodes de sf::Sprite, et ainsi ne pas surcharger l'interface publique des mes classes d'entité.
Mais on parle toujours d'héritage, et non de composition  ;)


Tu peux aussi hériter de sf::Transformable pour manipuler ton sprite à ta guise, sf::Sprite héritant lui-même de sf::Transformable.
Justement, puisque sf::Sprite hérite de sf::Transformable, je ne vois pas l'intérêt d'hériter de sf::Transformable si j'ai déjà un attribut sprite, ce serait redondant d'avoir 2 fois la matrice de transformation, et d'appliquer 2 fois les transformations (il faut bien transmettre l'info dans les sf::RenderStates au moment de dessiner le sprite).

Citation de: mccusti
Donc ça permet, comme le disait Laurent, de supprimer des méthodes auxquelles l'utilisateur ne doit pas avoir accès.
L'héritage privé m'a l'air la solution la plus adéquate pour ça (+ l'astuce de Hiura pour autoriser certaines méthodes uniquement), et celle qui requiert le moins de code également.

(Je n'ai pas lu toute la discussion, cette technique générale ne s'applique donc pas forcement à ton cas!)
Rien à voir avec le problème de l'OP, j'ai juste rebondi sur une citation de Laurent
« Modifié: Juillet 24, 2012, 02:29:12 pm par Haze »

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Messages: 4321
    • Voir le profil
    • E-mail
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #28 le: Juillet 24, 2012, 02:48:32 pm »
Citer
Mais on parle toujours d'héritage, et non de composition
Pas tout à fait, la nuance est subtile : on parle d'héritage privé et de composition. Ces deux choses sont pratiquement (dans les deux sens du terme, i.e., «pratique» et «approximatif») la même chose. Cline le décrit comme une variante syntaxique.
SFML / OS X developer

Haze

  • Full Member
  • ***
  • Messages: 201
    • Voir le profil
    • Github Profile
Re : Demande d'infos : sfml 1.6-2.0, ATI et solutions
« Réponse #29 le: Juillet 24, 2012, 03:07:04 pm »
Ok. Si on a les avantages de la composition tout en conservant l'aisance syntaxique offert par l'héritage, c'est tout bon je trouve.