Forum de la communauté SFML
Général => Site web SFML => Discussion démarrée par: christophedlr le Septembre 04, 2012, 04:10:12 pm
-
Bonjour,
Cette question s'adresse à Laurent. Laurent, l'écriture des tutos SFML 2.0 en est où ? Car sur le site, tutos comme doc c'est écrit la 1.6, la 2.0 en version future alors que d'après l'annonce que tu avais faite la SFML 2.0 est sortie. Elle n'est cela dit pas présente non plus dans downloads.
Merci d'avance pour ta réponse.
-
d'après l'annonce que tu avais faite la SFML 2.0 est sortie
Euh non. J'ai fait une release candidate, mais la version 2.0 finale n'est toujours pas sortie. Elle ne sortira pas tant que les tutoriels ne sont pas finis (c'est même tout ce qu'il me reste à faire, la version en elle-même est prête depuis longtemps).
Et les tutoriels seront prêts quand j'aurai le temps ;D
-
Bon ben bien que ça manque de date, au moins l'information est claire ;) Merci pour ta réponse.
-
Je me permets de ressusciter ce topic :)
Elle ne sortira pas tant que les tutoriels ne sont pas finis (c'est même tout ce qu'il me reste à faire, la version en elle-même est prête depuis longtemps).
Laurent, serais-tu intéressé si quelqu'un se chargeaient des tutoriels ? Par exemple, pour commencer, on pourrait transformer les tutoriels pour la 1.6 à la 2.0 :)
-
Les tutoriels sont à peu de choses près terminés (la moitié est même déjà en ligne). Il faut que je finalise la nouvelle version du site web et ce sera bon.
-
Oui cela serait génial pour continuer mon projet. :)
-
En attendant, tu as la documentation et les exemples qui devraient être suffisants pour te débrouiller...
-
Oui mais bon je ne vais pas toujours remodifier mon code, si je commence à faire ça je ne vais pas avancer, de plus je n'utilise pas que la SFMl comme librairie, et du fait que je change carrément de plateforme et qu'il me faut déjà tout résinstaller. :/
Même si la sfml n'est pas longue à compiler contrairement à certains autres librairies, le fait de devoir en + modifier mon code par la suite ne me motive pas à changer, la version 1.6 de la SFML, me suffit amplement pour ce que je veux faire. ^^
La SFML2 est trop compliquée pour ce que je veux faire, le fait que la SFML1.6 regroupe juste certaines autres librairies pour le raiseau, le son, les threads, etc... et me permette de ne pas devoir les utiliser indépendement et de pouvoir les utiliser plus simplement aussi ça me suffit largement.
Et puis de toute façon, contrairement à toi Grégoire, dans le domaine du gaming developpement je ne fais que commencer..., alors j'ai pas envie de me lancer dans des trucs trop compliqué pour l'instant.
-
L'API de SFML 2 ne changera plus, il n'y a vraiment plus que les tutos et le site web qui bloquent sa sortie finale.
La SFML2 est trop compliquée pour ce que je veux faire
??
En quoi est-elle plus compliquée que 1.6 ?
Et puis de toute façon, contrairement à toi Grégoire, dans le domaine du gaming developpement je ne fais que commencer..., alors j'ai pas envie de me lancer dans des trucs trop compliqué pour l'instant.
Le truc compliqué ce serait de te lancer dans SFML 1.6, qui n'est plus maintenant depuis presque 3 ans, comporte de sérieux bugs et n'est plus utilisée par personne sur ce forum ;)
-
??
En quoi est-elle plus compliquée que 1.6 ?
Bah plus compliquée peut être pas mais je n'ai pas besoin des VertexArray, les sf::shape me suffisent.
Et si je veux faire des dégradés je suis obligé de modifier tout mon code en remplaçant mes sf::Shape par des VertexArray si je passe à la SFML2.0 et ça m'embête.
Le truc compliqué ce serait de te lancer dans SFML 1.6, qui n'est plus maintenant depuis presque 3 ans, comporte de sérieux bugs et n'est plus utilisée par personne sur ce forum ;)
Je n'ai jamais eu de soucis avec la SFML 1.6 pour le moment, chez moi, elle a toujours très bien fonctionné.
Et puis bon quand je lis une librairie simple d'utilisation, en général je vais dessus et je regarde si elle est plus simple à utiliser qu'une autre librairie, si oui je la garde, si pas je la vire et je garde une plus grosse librairie.
Surtout si je dois commencer à utiliser des VertexArray et matrice de transofmration pour faire de la 2D. :/
Autant repassé à opengl
-
Le retrait de fonctionnalités est très rare, et en effet celle-ci (les dégradés dans sf::Shape) m'a clairement embêté ; mais je n'avais pas vraiment le choix.
L'équivalent en sf::VertexArray peut être très simple, si tu n'utilises pas de bordure. Je pourrai te donner un exemple si tu veux.
-
Et puis de toute façon, contrairement à toi Grégoire, dans le domaine du gaming developpement je ne fais que commencer..., alors j'ai pas envie de me lancer dans des trucs trop compliqué pour l'instant.
A ma connaissance tu fais ça depuis quelques années déjà et tu as fini tes études d'informatique... Donc apprendre une bibliothèque comme la SFML ne devrait pas être un défi insurmontable pour toi !
Quant à juste passer de la SFML 1.6 à la 2.0, ça m'a pris une petite après-midi pour le faire dans les 35 000 lignes de code d'Holyspirit, donc bon, faut faire la différence entre flemme et "ça va me prendre beaucoup trop de temps".
Et si tu as besoin d'exemples ou quoi pour les vertexarray : http://lechemindeladam.svn.sourceforge.net/viewvc/lechemindeladam/trunk/Source/Moteurs/light.cpp
-
Ok, en tout cas je peux dire que en réseau, avec la SFML 1.6 mon personnage avance d'une façon assez bizarre et fort lente, je ne sais pas si c'est parce que :
-Je lance le serveur et le client sur une même machine ce qui fait laguer mais pas trop le choix.
-La SFML 1.6 comporte encore trop de bug. (De plus mon projet est en configuration débug, peut être pour ça.)
Bref il faut encore que je fasse différents test pour voir ça, et en effet je ferai aussi des tests avec la SFML 2.^^ (Bien que je doute que ça soit plus rapide avec ça.)
A ma connaissance tu fais ça depuis quelques années déjà et tu as fini tes études d'informatique... Donc apprendre une bibliothèque comme la SFML ne devrait pas être un défi insurmontable pour toi !
En effet, j'avais même réussi à remplacer tout ça par des VertexArray et ConvexShape pour les ombres car pour les ombres, pas besoin de dégradés, cependant, même si j'ai fais des études et que en fouillant dans la doc j'arrive toujours à trouvé une solution, j'ai horreur de devoir modifié du code, sans doute parce que j'ai beaucoup appris la programmation modulaire et surtout, comment ne pas devoir modifier trop de code si mon programme évolue, mais bon t'a pas tord Grégoire il va falloir je pense que je me décide à mettre plus les mains dans le cambouilli. (Car bon en effet la SFML est fort récente comparé à d'autres librairie comme QT ou je dois changé peu de code entre chaque versions. :/)
-
Je lance le serveur et le client sur une même machine ce qui fait laguer mais pas trop le choix.
Tout dépend de ce que ton application fait. Mais si ta machine ne supporte pas deux instances de ton application en parallèle, alors peut-être qu'elle est trop lourde et/ou pas assez optimisée ?
En tout cas côté purement réseau, le fait d'être sur la même machine n'a aucune chance de faire chuter les perfs. Au contraire, tu t'affranchis du lag inhérent au réseau si tu utilises l'adresse "localhost" (127.0.0.1) pour te connecter à toi-même.
La SFML 1.6 comporte encore trop de bug
Il y a une différence entre bug et mauvaises perfs ;)
La 1.6 ne devrait pas poser plus de soucis que la 2.0 côté performances.
De plus mon projet est en configuration débug, peut être pour ça.
Ca peut effectivement être la raison. Il ne faut jamais tester les performances en mode debug.
je ferai aussi des tests avec la SFML 2.^^ (Bien que je doute que ça soit plus rapide avec ça.)
SFML 2 sera plus rapide uniquement sur un cas typique : plusieurs sprites utilisant la même texture (typiquement un niveau à base de tiles, ou des particules, etc.), avec SFML 2 tu peux tous les dessiner en un coup avec un vertex array, et là tu vois nettement la différence (ce qui a le plus d'impact sur les performances, c'est le nombre d'appels à la fonction draw).
-
-Je lance le serveur et le client sur une même machine ce qui fait laguer mais pas trop le choix.
Il y a de fortes chances que ta façon de faire ne soit pas bonne, revois ton architecture et tes algorithmes.
Car bon en effet la SFML est fort récente comparé à d'autres librairie comme QT ou je dois changé peu de code entre chaque versions. :/
J'ai envie de dire que ça tu le savais déjà avant de commencer... C'était un pari à prendre en développement avec la SFML.
Maintenant en contrepartie tu as une bibliothèque très vivante qui ne fait que s'améliorer et ce rapidement !
-
Il y a de fortes chances que ta façon de faire ne soit pas bonne, revois ton architecture et tes algorithmes.
Bah, écoutes, au niveau algorithme il est pas bien fort différent du tiens vu que je m'en suis inspiré et je l'ai amélioré, pour les déplacements au clavier, le client envoie la nouvelle position du personnage au serveur, le serveur récupère la case avec une bête formule et voie alors si il peut passer sur la case ou pas, si oui, le serveur dis au client que le personnage peut avancer et il avance, sinon, il n'avance pas.
Je ne vais pas parler des déplacements à la souris ou là j'ai fais un propre algorithme mais ce sont des algorithmes tout simple pourtant et donc rapide, la seule chose que j'ai fais de plus, c'est un cryptage symétrique que toi tu n'avais pas fais..., bref je vais voir si avec la SFML2 ça va mieux car la mes déplacements sont complètement saccadé. :/
Voici une petite vidéo pour mieux comprendre. (Et encore je n'ai même pas encore fait les animations des personnages, j'ai utilisé un personnage d'un autre jeux juste pour les test.)
http://www.youtube.com/watch?v=pgpt3g50BC8 (Mon personnage n'avance pas puis avance tout à coup. :/)
Pourtant j'ai bien utilisé un sf::clock pour les déplacements en temps réel bref...
Et aussi, j'utilise la SFML avec Qt car j'ai besoin de QT pour créer les interfaces de création de personnages.
PS : J'ai bien sûr aussi essayer d'utiliser un Thread pour les déplacements de personnage mais, dans ce cas là, l'image clignote. :/
Mais bon normalement ça devrait pas être si saccadé, que ça soit avec ou sans thread.
-
Et sans réseau, tu saccades aussi ?
Je ne vois pas l'intérêt de passer par un thread pour gérer les déplacements, par contre j'imagine que tu en utilises pour gérer la réception de paquets ?
-
Et sans réseau, tu saccades aussi ?
Non sans le réseau ça va.
Je ne vois pas l'intérêt de passer par un thread pour gérer les déplacements, par contre j'imagine que tu en utilises pour gérer la réception de paquets ?
Oui, c'est même obligé, sinon, dès que je lance le moteur réseau pour la réception de paquets, la fenêtre freeze et je ne sais plus rien faire.
Bref ce ralentissement vient des threads je pense, je pensais peut être au départ que ça venait des mutex mais je ne pense pas, peut être que avec la SFML2 ça ne saccadera plus, bref on verra.
Ou bien alors je dois, faire la réception de paquets dans ma boucle principale et non dans un thread mais bon ça m'étonne que ça saccade ainsi surtout que mon processeur c'est une quad core. :/ (Et de plus on va commencer à passé de plus en plus en multi-thread maintenant au niveau gaming : un pour la réception réseau, un autre pour l'IA, le thread pour l'affichage (c'est le thread principal.) et un thread pour la gestion des collisions.
Bref en général j'utilise 4-5 thread car on fait plutôt des processeur multi-core maintenant, vu que sinon ça consomme trop.
PS : juste pour info, ma boucle principale c'est la méthode update de Qt qui est appelée en boucle par Qt vu que j'utilise Qt et la SFML, et cette boucle est lancée des que la map est chargée, je suis entrain de réfléchir comment je pourrais faire en fait sans utiliser de thread pour la réception de paquets pour voir si ça saccade toujours autant..., bref..., je dois avouer que je galère un peu, je ne sais pas très bien comment faire. :/
-
En fait, c'est pas trop l'endroit pour discuter de tout ça, mais faudrait que tu me donnes plus de détails sur ton architecture sinon je ne sais pas trop dire grand chose.
-
En effet ce n'est pas trop l'endroit pour discuter de ça, je te contacte sur msn. ;)
-
Heu tu te co quand ?
Sinon il semblerait que ce ne soit pas le réseau, mais ma méthode OnUpdate qui est appelé en boucle par Qt qui est lente. :/ (J'ai à peu près du 1 voir 2 de FPS maxi. :/)
Faut que je trouve un moyen pour accélérer ça. :/
Je vais toujours voir avec la SFML 2 si cela ne va pas plus vite au niveau de l'affichage déjà, en utilisant des textures de rendu plutôt que le print-screen, la seule chose qui me gêne c'est quand il faut mettre des coordonnées négatives aux render textures vu qu'on ne peut plus faire de flipX et flipY comme avec la SFML 1.6 mais bon ce n'est pas grave, je vais pouvoir quand même me débrouiller.
-
Bon, avec la SFML 2.0 ça saccade moins donc je vais rester avec la SFML 2.0.
Sur ce je vous laisse car il me reste encore quelques petites choses à tester. ;) (Les RenderTexture et les VertexArray et ConvexShape entre autre pour mes ombres et mes lumières. ;)