Demande d'infos : sfml 1.6-2.0, ATI et solutions

[coco]

Bonjour à tous !

Je travaille actuellement sur un jeu ( Exodus ) utilisant un moteur de jeu maison, lui-même basé sur SFML. Nous utilisons une version un peu modifiée de SFML ( je ne connais pas exactement les détails des modifications effectuées, mais je pourrais me renseigner ), et nous sommes basés sur une version de SFML pré-2.0 ( un peu avant les changements de noms, l'ajout de transformable... ). Je n'ai pas toutes les infos a ce sujet puisque ce n'est pas moi qui m'en suis occupé, mais je pourrais obtenir des compléments d'info si besoin.

Sur la version de SFML que nous utilisons, nous avons encore le bug connu sur les cartes ATI, ce qui doit être "normal". J'ai cherché un peu sur le forum les solutions possibles :

- Passer à la sfml 2.0 : Nous avons déjà essayé, mais nous avons eu plein de soucis ( probablement dus au modifications que nous avons faites sur SFML, entre autres ), et nous pensons que ça nous prendrait beaucoup de temps.

- Version Static : Ce que j'essaye depuis un petit moment. Effectivement, ca corrige le pb sur les ATI, cependant j'ai 2 soucis avec la static que je n'ai pas avec la dynamic : Il semble qu'avec du nvidia ( au moins sur 2 pc différents ), j'ai un problème sur les images chargées dans un thread : elle restent blanches jusqu'à ce que j'arrive dans leur map, puis elles s'affichent. Au bout d'un petit temps, le jeu ( framerate ), voir le pc, commencent a partir en vrille ( j'ai eu des freezes de l'OS sur mon pc perso ( Trust ) ). Sur ATI en static, ça semble fonctionner correctement, mais au bout d'un temps, le framerate tombe à 10 ou moins, et le rendu des sprites prend vraiment beaucoup plus de temps qu'avant ( plus de RAM graphique ? ).

A savoir que je considère que le tout fonctionne "parfaitement" avec notre version de sfml en dynamic, mis a part sur les ATI.

Du coup après avoir un peu tout testé ( je crois ), je tenterai bien de corriger le bug ATI sur la dynamic de notre version ( même si c'est la solution la moins simple en théorie, mais dans notre cas je ne sais plus trop quelle solution est la plus simple ). Pour cela, j'aurais apprécié d'avoir quelques infos sur les sections qui posaient problème sur une ATI en dynamic ( je suppose les modules window et/ou graphic, mais quoi exactement ? ).

Toute aide sera la bienvenue =)

Colin

ps: Je sais que le sujet a déjà été largement traité, j'ai cherché avant de poster, mais il est possible que j'ai manqué le bon thread...

ps2: Pour l'instant nous travaillons sur Windows.

[Laurent]

Ces problèmes que tu as avec la version statique... c'est pas normal du tout.

Pour ce qui est de corriger le bug ATI, l'énoncé est simple : il faut éviter la construction/destruction de contexte OpenGL en dehors du main() (je ne sais plus exactement où cela arrive avec un vieux SFML, il faut fouiller le module Window).

Mais franchement bon courage, j'ai dû reprendre toute la gestion des contextes OpenGL pour corriger ce bug. Mais votre version pré-2.0 est si vieille que ça ?

Le mieux serait sans doute de vous mettre à jour sur la toute dernière version. Et de me parler des modifications que vous avez effectuées.

[coco]

Je suis d'accord pour la static, étant donné que nous avons commencé a travailler avec la static, sans avoir de soucis, puis nous sommes passés sur la dynamic il y a un an environ ( sans avoir connaissance du bug ATI ). Je pense que ce problème de static vient de nous, j'ai essayé de chercher ( pb de compil et/ou de libs ? ), mais j'ai pas encore trouvé...

Je pense aussi que passer sur la 2.0 serait la meilleure solution ( je crois en plus que certaines optis ont été appliquées, ce qui pourrait nous être utile... ), mais mon collègue avait déjà essayé et rencontré plein de soucis ( je lui laisse la main pour expliquer ces problèmes et les modifs qu'il a fait sur la SFML, quand il aura le temps ).

Le développement de notre moteur maison a  débuté il y a 3 ans sur la 1.6, nous avons essayé de mettre a jour en même temps que tu mettais a jour SFML vers 2.0, mais il y'a eu un soucis lors de changements majeurs, et on a décider de rester sur la version qui fonctionnait. Et ça nous retombe dessus maintenant ^^

Donc oui, ça date un peu =)

Je vais essayer de tracer la dynamic sur un pc avec une ATI pour voir ce que ça donne. Merci pour les infos en tout cas ^^

Edit :

Yeah !!

J'ai réussi a contourner le problème ( la fenêtre qui ne s'ouvre pas sur ATI ) en changeant les ContextType "referenceContext" et "defaultContext" (GlContext.cpp) en pointeurs. J'ai fait une fonction pour les créer et une pour les détruire que j'appelle au tout début et en toute fin du main. Du coup, le programme se lance normalement. Cependant, j'ai toujours ce problème de framerate qui tombe au bout d'un temps, je vais faire des tests sur d'autres configs pour voir si ça semble venir d'ATI ou de notre version d'SFML et/ou moteur.

En tout cas, merci pour l'info, ça m'a beaucoup aidé !!

[coco]

Comme par hasard, on trouve toujours ce qu'on cherche après avoir posté :

http://en.sfml-dev.org/forums/index.php?topic=3438.0

On a toujours des soucis de framerate/freeze nvidia. Je suppose que ca vient de nous (moteur ou version de sfml ). On va donc essayer de passer sur la dernière 2.0

D'ailleurs il s'avère que nous n'avions pas fait de modifs internes a sfml, juste quelques const_cast pour pouvoir accéder a certains éléments. Mon ignorance me fait dire des bêtises ^^

Sinon pour le bug ATI sur la dynamic de la 1.6, effectivement il suffit de faire une fonction init et deinit et de passer les contextes réference et default en pointeurs. Je pourrais modifier les 3-4 fichiers nécessaires sur la 1.6 et les partager s'il y a encore des personnes qui rencontrent ce problème.

To be continued... =)

[Laurent]

Comme par hasard, on trouve toujours ce qu'on cherche après avoir posté

Mince, je ne me souvenais plus du tout que j'avais déjà donné une solution détaillée, désolé
En tout cas c'est bien, vous avez tout de suite réussi à trouver la bonne solution.

Sinon pour le bug ATI sur la dynamic de la 1.6, effectivement il suffit de faire une fonction init et deinit et de passer les contextes réference et default en pointeurs. Je pourrais modifier les 3-4 fichiers nécessaires sur la 1.6 et les partager s'il y a encore des personnes qui rencontrent ce problème.

SFML 1.6 est déjà plus ou moins obsolète, je ne sais pas si ça vaut le coup.
En plus la correction serait sans doute un peu différente, j'avais déjà fait des modifs sur les contextes dans la version que vous utilisez -- si je me souviens bien.

[coco]

Le portage est en cours ( argh tous les noms ont changé ! )...

J'ai cru comprendre que la fonction draw remplace la fonction Render, mais elle est passée de protected à private, du coup impossible de l’appeler dans une classe fille ( a moins que mes connaissances en C++ ne soient un peu limitées ou que j'ai omis un détail... ).

Pour prendre un exemple, on a surchargé le draw du Text pour ajouter des appels openGL ( clip plane ) avant et après le draw, ce qui n'est plus trop possible apparement. De plus, il me semble impossible de refaire le draw du text "simplement" puisque tout est en private...

Aurais-je loupé une info ?

ps : C'est bien la classe ConvexShape qui propose les même possibilités que l'ancienne classe Shape ?

[kimci86]

Bonjour,
La méthode draw remplace la méthode ... Draw.
Chez les Drawables, elle est protected.
Celle des RenderTarget est public.

Pour la classe personnalisée de texte, il faudrait:

void CustomText::draw(sf::RenderTarget& target, RenderStates states) const
{
    /*
    mettre en place le clipping
    */

    // on dessine l'objet en tant que sf::Text
    sf::Text::draw(target, states);

    /*
    mettre fin au clipping
    */
}

J'espère vous avoir aidé.

[coco]

C'est ce que j'ai essayé de faire en premier, mais mon compilo n'aime pas trop l'appel a une fonction privée de la classe mère dans une classe fille ( en héritage public )...

Pour la fonction Render, c'est ce qu'on redéfinissait ( en tant que draw ) sur notre ancienne version de SFML. C’était peut être des modifs temporaires entre la 1.6 et la 2.0...

[Laurent]

La fonction draw est protégée, pas privée.

Render était en effet une modif intermédiaire.

[coco]

Sur la version sfml que j'ai téléchargé ( 2.0 rc ), elle est effectivement protégée sur Drawable, mais privée sur sf::Text. Et ceci ne compile pas :

namespace cream
{
//...
void Text::draw(sf::RenderTarget& target, RenderStates states) const
{
    /*
    code
    */

    // on dessine l'objet en tant que sf::Text
    sf::Text::draw(target, states);

    /*
   code
    */
}
//...
}
 

( impossible d'accéder à private membre déclaré dans la classe 'sf::Text' )

Ce code est censé compiler ?

Par ailleurs, Je ne comprends pas bien pourquoi elle est protégée sur Drawable et privée sur Text, Shape, Sprite...

Du coup, dans les classes qui en héritent, on est censés mettre le draw en protected ou en private ?

[kimci86]

Je pense que cette astuce peut fonctionner:

void cream::Text::draw(sf::RenderTarget& target, RenderStates states) const
{
    /* ... */
    target.draw(static_cast<const sf::Text&>(*this), states);
    /* ... */
}

[Laurent]

Ce code est censé compiler ?

Non

Par ailleurs, Je ne comprends pas bien pourquoi elle est protégée sur Drawable et privée sur Text, Shape, Sprite...

C'est un moyen un peu vicieux de décourager les gens à dériver de ces classes. Elles ne sont pas vraiment faites pour.

Du coup, dans les classes qui en héritent, on est censés mettre le draw en protected ou en private ?

Comme tu veux, c'est toi qui décide de la conception de ta classe en fonction de son utilisation prévue. Mais dans tous les cas tu ne pourras pas appeler celle de la classe mère.

Je pense que cette astuce peut fonctionner:

Non, ça va rappeler cream::Text::draw puisqu'elle est virtuelle.
Cette limitation étant conceptuelle (et donc voulue), pas besoin de chercher d'astuce pour contourner. Si je voulais que ce soit possible je changerai directement l'accès de privé à protégé dans les classes concernées

[kimci86]

Quelles sont donc les raisons de telles limitations ?

[Laurent]

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.

[coco]

C'est donc bien intentionnel ^^. Du coup je vais essayer de récupérer les sources et faire cette modif' ( private => protected ), parce que j'en ai vraiment besoin ( impossible de revoir tout le design du moteur juste pour ça pour le moment ).

Je ne suis pas sur de pouvoir fournir un excellent contre exemple, ou encore d'affirmer que notre solution est valable du point de vue design. Nous héritions des classes sfml principalement pour les interfacer avec nos systèmes de load/save a partir de fichiers / flux, 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... ). Nous avions aussi besoin de redéfinir les draw pour appeler automatiquement une update dans ce dernier ( mise a jour des animations pour les sprites, lancement&mise a jour de scripts lua, etc...).

Par exemple, pour les Sprites, nous avons redéfini les draw pour qu'ils gèrent certains cas supplémentaires ( animations/spritesheets etc... ), mais comme on utilise directement openGL pour afficher ( ou le Renderer à l'époque ou il existait ), on n'a pas ce souci protected/private. Par contre pour les textes, ça nous arrange de ne pas refaire l'affichage, qui doit être un brin plus complexe que celui de Sprite =)

On pourrait aussi sortir l'activation / désactivation des clip planes du draw pour l’appeler avant/après chaque affichage de texte, mais c'est beaucoup plus pratique que ce soit directement intégré dans le draw ( surtout quand on a un moteur et 3 jeux qui tournent dessus à convertir )

En tout cas, merci pour les infos =)