Passer de SFML1.6 vers SFML2.0?

[Crone123]

Bonjour,
J'ai des bugs réseau (TCP qui bloque, UDP aussi, pour des raisons inconnues) avec la SFML 1.6 et j'ai lu qu'à priori c'est un problème de la bibliothèque qui est corrigé dans la version 2.0.

La SFML étant ma bibliothèque préférée j'aimerais avoir quelques renseignements pour passer mon projet a la SFML 2.0.

Donc déjà, la SFML 2.0 corrigera t-elle les bugs réseaux que j'ai avec la 1.6? C'est à dire des socket qui se bloquent notamment en écoute si on les utilise soit un peu trop, soit pour je ne sais quelle raison ici j'arrive même pas a me connecter a un serveur de jeu le socket plante tout de suite (ça le fait pas a chaque fois, ni sur tous les ordis, mais a la longue c'est assez embêtant..)
→ Quand le socket est planté, je peux envoyer des données, le serveur me reçois, mais je ne peux plus en recevoir..
Et des fois j'ai le socket qui reste bloqué sur "NOT_READY" pendant 30s....assez gênant quand le jeu doit passer des données importantes....

Donc, je sais que la SFML 2.0 propose beaucoup de fonctions supplémentaires, et je pense qu'en regardant ce qui est proposé je pourrais trouver beaucoup de choses qui me servirons, maintenant ce qui m’intéresse c'est surtout pour l'histoire du bug réseau....si la SFML 2.0 le corrige c'est ma raison principale de vouloir passer de l'un a l'autre.

Je sais que je vais avoir du code a modifier, déjà passer toutes les fonctions de la SFML de Majuscules au début vers tout en minuscules, mais y a t-il beaucoup de code a changer en dehors?

Les Sprites restent des Sprites? Les Images restent des Images? Les sf::Sound restent des sf::Sound?
Ces objets ont t-ils des modifications importantes qui nécessiterons beaucoup de modifications dans mon code? (Mon projet fait quand même 13000lignes de code, donc j'ai déjà quelques lignes a modifier...)

Ensuite, j'ai des question importante pour la compatibilité:
J'utilise beaucoup les sf::Shape, ces objets sont géniaux notamment pour des boutons simples, des effets de surbrillance, ou encore des barres de vies/chargement et même des traînées...

Je vois par exemple que la fonction sf::Shape::AddPoint n'existe plus dans la SFML2.0, et je n'ai pas trouvé d'équivalent...en existe t-il un? Lequel? (note, je fais des rectangles, mais il m'arrive souvent que ce soit des quadrilatères quelconques....)

Que sont les sf::Texture qui jusque là n'existaient pas? Quelle différences avec un sf::Image par exemple?

Le Rendu SFML est inclus dans Qt (QWidget), le code sera t-il différent pour l'inclure dedans?

Voilà, un message un peu long pour tout ça, mais c'est des points indispensable je pense parce que pour l'instant je suis un peu dépaysé en voyant la doc de la SFML 2.0...
Merci beaucoup

[Laurent]

Donc déjà, la SFML 2.0 corrigera t-elle les bugs réseaux que j'ai avec la 1.6?

Je n'ai jamais entendu parler de tels bugs avec SFML 1.6, donc j'ai de forts doutes quant au fait qu'il s'agisse de bugs de SFML. Ne pourrait-il pas s'agir de problèmes avec ton propre code ? As-tu essayé de reproduire le problème avec un code complet et minimal ?
Dans tous les cas si tu veux continuer à parler de ce problème en particulier, je te conseille d'ouvrir une nouvelle discussion dédiée à celui-ci.

y a t-il beaucoup de code a changer en dehors?

Les Sprites restent des Sprites? Les Images restent des Images? Les sf::Sound restent des sf::Sound?

Certaines parties sont identiques, d'autres ont complètement changé. Malheureusement il n'y a pas de changelog ou de guide de portage exhaustif, mais en regardant mes posts dans le forum anglais General > General discussions (j'en ai aussi posté la majorité sur le forum français, mais pas tous), tu devrais avoir des informations quant aux modifications les plus importantes qui ont été faites sur l'API.

Je vois par exemple que la fonction sf::Shape::AddPoint n'existe plus dans la SFML2.0, et je n'ai pas trouvé d'équivalent...en existe t-il un?

Le système de shapes a changé, les différentes formes ont maintenant chacune leur classe dédiée. La classe sf::ConvexShape reproduit la plupart des fonctionnalités de la classe sf::Shjape de SFML 1.6. Avec ses fonctions setPointCount et setPoint, tu as l'équivalent de l'ancien addPoint.

Que sont les sf::Texture qui jusque là n'existaient pas? Quelle différences avec un sf::Image par exemple?

Il y a une discussion sur le forum qui explique tout ça de manière détaillée.

Le Rendu SFML est inclus dans Qt (QWidget), le code sera t-il différent pour l'inclure dedans?

A priori non.

Il est difficile de te dire tout ce qui a changé, mais n'hésite pas à poser des questions sur des points plus précis.

[Crone123]

J'ai essayé la bibliothèque, j'ai pas eut trop de mal a l'utiliser a la place de la 1.6, sauf qu'il faut utiliser les sf::Texture au lieu des sf::Image. (et les minuscules...faudra que je m'y habitue, j'ai l'habitude d'en mettre partout..)

Pour les sf::Shape, c'est parfait alors

J'ai aussi remarqué beaucoup de choses plus simples qu'avant, notamment pour tester le clavier, le changement est vraiment bien fait

Pour le réseau, faudra que j'essaie, mais par exemple le joueur envoie ses positions, ou en reçois et hop, ça peut bloquer parce que ça a été utilisé..le serveur envoie une map (de façon modérée pour que le client puisse suivre bien sûr), hop, ça coince.

Sur un réseau local pour le transfert d'une map je ne peux pas dépasser les 400 ou 500ko/s sinon le socket coince..

J'essaierais avec la SFML2.0 pour voir
Je ferais des tests, et j'essaierais de voir d'où ça viens, mais en théorie ça ne devrait pas bloquer pourtant...

J'ai encore quelques question:
Comment capter les événements comme dans la SFML1.6 pour fermer la fenêtre par exemple?
Où se trouve le sujet sf::Image/sf::Texture?
Niveau performances, la SFML2.0 les améliore? Niveau vitesse de rendu, etc? (simple curiosité )

Je pense sinon je j'arriverais plutôt bien a m'adapter après avoir un peu essayé, je vais encore tester un peu la bibliothèque, et je passerais mon Projet a la SFML2.0
Merci

[Laurent]

Comment capter les événements comme dans la SFML1.6 pour fermer la fenêtre par exemple?

Et bien tu l'as dit : comme dans SFML 1.6
En plus le tutoriel correspondant pour SFML 2.0 est déjà en ligne, donc n'hésite pas.

Où se trouve le sujet sf::Image/sf::Texture?

Ici http://en.sfml-dev.org/forums/index.php?topic=5503.0
Et là https://github.com/SFML/SFML/issues/18

Niveau performances, la SFML2.0 les améliore? Niveau vitesse de rendu, etc?

Disons qu'elle permet des optimisations côté utilisateur qui n'étaient pas possibles avant. Des optimisations assez primordiales (comme pouvoir afficher une grosse géometrie statique en un seul appel).

[Crone123]

OK, j'ai regardé, j'ai compris et vu les différences entre les 2 classes.
L'inconvénient est de ne pas pouvoir convertir une Texture en Image, ça serait bien de pouvoir le faire. (Si je me trompe, corrigez moi )

Donc pour afficher une map de beaucoup de sf::Sprite (générées a la volée), ça sera plus rapide avec les sf::Texture de la SFML 2.0?

Pour les Chronomètres, j'ai vu une amélioration un peu perturbante les premières minutes, et c'est aussi du code a modifier, mais c'est pas du tout idiot les variables sf::Time et la fonction restart, je trouve ça plutôt bien pratique

Pour les Threads c'est un peu moins bien qu'il n'y ai plus le constructeur vide.
ça me permettait de faire des classes perso héritant de sf::Thread qui se lançaient et se fermaient en modifiant différentes variables internes a l'objet...

Pour QSFMLCanvas il faut modifier un peu de code, donc toujours les majuscules, et aussi, important si vous refaites un exemple sur les tutos:
la fonction: "create(winId());" qui est appelée, la SFML avant appelait "Create()", mais maintenant "create()" est en conflit avec Qt (c'était ma crainte en fait les conflits de fonction quand j'ai vu que la SFML n'avait plus ses majuscules..., setPosition va aussi être en conflit...)
Il faut donc appeler:
"sf::Window::create(winId());" a la place, sinon vous aurez un pb avec Qt....

Bon, sinon pour l'instant ma conversion 1.6 -> 2.0 avance...en dehors des Threads qui ont été un peu problématique un moment (et j'espère que ça va marcher) j'ai pas eut de soucis pour l'instant

Et c'est appréciable que la Bibliothèque soit pré-compilée, parce que je ne sais pas compiler la plupart des trucs qu'on me donne (ou alors c'est une catastrophe..), SPARK par exemple pour l'inclure a la SFML je n'arrive pas a le compiler sous Linux....(la 1.6 je l'avais dans les dépôts d'Ubuntu)

J'ai crée un SDK avec des fonctions utiles pour mes Projets, je suis en train de l'adapter pour l'instant ça va.
Et après j'adapte le jeu en lui même pour lequel je ne devrais a priori pas avoir de problèmes en dehors du fait que ça prendra un peu de temps...

Si j'ai d'autres problèmes ou questions je posterais sur le forum alors (Enfin, après avoir cherché dans la doc bien sûr )
Merci

EDIT: En fait non, pour les threads c'est génial la nouvelle façon de les utiliser, ça permet de mettre n'importe quelle fonction d'un objet en thread, bravo !

[Laurent]

L'inconvénient est de ne pas pouvoir convertir une Texture en Image

sf::Image image = texture.copyToImage();

Donc pour afficher une map de beaucoup de sf::Sprite (générées a la volée), ça sera plus rapide avec les sf::Texture de la SFML 2.0?

Non. Pour gagner en performances il faut grouper un maximum de géometrie dans une seule entité, et ceci est possible avec les vertex arrays.

Pour les Threads c'est un peu moins bien qu'il n'y ai plus le constructeur vide.
ça me permettait de faire des classes perso héritant de sf::Thread qui se lançaient et se fermaient en modifiant différentes variables internes a l'objet...

Il n'y a jamais eu de "constructeur vide". Avant avec héritage, le lien entre l'instance de sf::Thread et la fonction à exécuter était encore plus figé. Avec le nouveau système, tu peux reproduire exactement le comportement de l'ancien, mais pas uniquement. Donc c'est mieux

en dehors des Threads qui ont été un peu problématique un moment

En attendant d'apprendre à les utiliser mieux, tu peux refaire une équivalence stricte avec l'ancien système :

class MyThreadedClass
{
public:

    MyThreadedClass() : m_thread(this, &MyThreadedClass::Run)
    {
    }

    void Launch()
    {
        m_thread.launch();
    }

private:

    void Run()
    {
        ...
    }

    sf::Thread m_thread;
}

Et c'est appréciable que la Bibliothèque soit pré-compilée, parce que je ne sais pas compiler la plupart des trucs qu'on me donne

Ca s'apprend, faut pas partir défaitiste comme ça. C'est comme tout : c'est pas bien compliqué une fois qu'on a compris les choses obscures qui sont décrites dans les tutos

En fait non, pour les threads c'est génial la nouvelle façon de les utiliser, ça permet de mettre n'importe quelle fonction d'un objet en thread, bravo !

Ah, bon ben voilà

[Crone123]

OK, bah c'est cool si on peu les re-transformer en sf::Image !

Je verrais pour les perfs alors
Merci

[Laurent]

OK, bah c'est cool si on peu les re-transformer en sf::Image !

Normalement on ne devrait avoir besoin de cette fonctionnalité que dans de rares cas très précis, tu comptes t'en servir pour quoi ?

[Crone123]

J'aimerais une fois tout les tremblements de terre modifier des pixels de ma texture, ce sera un cas rare qui n'arrivera quasiment pas dans le jeu (pas plus d'une fois toutes les 10min un truc comme ça...)
Donc a ce moment là je récupérerais la texture en sf::Image pour lui modifier ses pixels.
ça m'évitera de devoir charger 500 textures et 500 images, juste récupérer une sf::Image de temps en temps ça sera mieux je pense

-> Je ne compte bien sûr pas l'utiliser a chaque image au moment ou j'en ai besoin, ça ne sera utilisé qu'une fois et gardé dans un sf::Image static

En gros quand le joueur verra son personnage évoluer ce qui est rare je récupérerais la sf::Texture utilisée pour la modifier en mettant une animation pour l'évolution du perso
Merci