Messages

16

Projets SFML / Re : Re : [2.0] - Lecteur de musique very light

« le: Novembre 08, 2012, 05:21:34 pm »

Lorsque j'utilisais la boucle while, les sons étaient bien joués l'un après l'autre.
Ou alors c'est getDuration() qui ne vas pas ? je vais voir quelle est sa valeur.

sa valeur est la durée totale de ta musique.

Mais comme dit Laurent, sf::sleep est bloquante, du coup tant que sf::sleep ne s'est pas terminée, tu ne devrais pas pouvoir entendre la deuxième musique, vu que le loadFromMemory n'a pas été rappelé).

Question bête, t'es sur d'avoir compilé ?

17

Projets SFML / Re : Re : [2.0] - Lecteur de musique very light

« le: Novembre 08, 2012, 04:55:41 pm »

Il s'avère par contre que tous mes fichiers sons sont lus en même temps en utilisant sf::sleep :/.

Je ne penses pas que cela vienne du sf::sleep, c'est que play est une méthode non-bloquante (d'après la doc, le morceau est joué dans un thread qui lui est dédié, pour ne pas bloquer le reste du programme). Sans le sf::sleep, est tu sur que tes morceaux ne sont pas joués en même temps ?

la vérité est ailleurs

edit : issu de la doc de sf::Music::play(...) : Start or resume playing the audio stream.

This function starts the stream if it was stopped, resumes it if it was paused, and restarts it from beginning if it was it already playing. This function uses its own thread so that it doesn't block the rest of the program while the stream is played.

ce sera mieux qu'une traduction hasardeuse à partir de mon mauvais anglais

18

Discussions générales / Re : SFML et exceptions

« le: Novembre 08, 2012, 04:46:31 pm »

Encore une fois je penses que c'est une question de choix de conception : en terme de rigueur, robustesse, et/ou performances, cela reste de toute façon la meilleure approche (pour le gain de performance, je ne saurais l'expliquer, j'ai simplement lu un article qui allait dans ce sens).

Si la priorité est d'avoir un code léger et clair (ce que négligent un peu et très souvent (un peu trop et trop souvent à mon gout) les développeurs qui ont de fortes connaissances), qui laisse un peu plus de responsabilités à l'utilisateur (volontairement j'entends), il y a des méthodes pour.

Moi ce qui m'intéresse surtout, c'est qu'entends-tu par  "plus je me rend compte que la gestion des erreurs est très insatisfaisante" ?

Parce que je suis sur qu'il y a moyen d'avoir un système de gestion des cas d'erreurs, concis et clair, bien structuré et qui ne fait pas appel à des exceptions standards ou perso, donc ce serait super intéressant de savoir dans ce cas à quelles problématiques cela t'a conduit, vu que c'est cette dernière approche que tu avais choisi (peut-être pas assez franchement ?)

19

Discussions générales / Re : SFML et exceptions

« le: Novembre 08, 2012, 03:46:51 pm »

...et en venir aux exceptions ?

20

Discussions générales / SFML et exceptions

« le: Novembre 08, 2012, 02:49:48 pm »

Salut,

J'aimerais savoir pourquoi SFML ne lance pas d'exceptions donc je vais directement m'adresser au créateur :

(attention, je ne suis pas contre, je trouve que c'est une bonne idée, c'est pourquoi je veux m'assurer d'avoir compris le pourquoi du comment)

Pourquoi ce choix Laurent ? En plus de la raison que je soupçonne que des blocs try/catch et toutes les classes supplémentaire que ça oblige à coder, ça rend le code plutôt désagréable, y'a-t-il une raison technique ? Parce qu'en terme de performance, les gestion des exception a tendance à être mieux que les gestion "OK/KO".

Ou encore, est-ce un choix conceptuel du genre "je laisse la responsabilité à l'utilisateur de gérer les différents cas d'erreur, et je leur colle juste un petit warning sur l'erreur standard pour qu'il soit averti que ça risque de pêter" ? Ton objectif était-il de permettre aux programmes de continuer de tourner même avec des erreurs qui dans l'absolu n'ont pas de raison d'être bloquantes (par exemple un draw d'un sprite avec une texture vide est tout simplement ignorée ou des choses comme cela ?) ?

21

Discussions générales / Re : Re : Activité de SFML?

« le: Octobre 26, 2012, 09:25:00 am »

C'est vrai que ce serait bien de conclure proprement le ticket, au lieu de le laisser fermé sans explication.

Du coup j'ai ajouté un lien vers le topic correspondant sur le forum, que voici :
http://en.sfml-dev.org/forums/index.php?topic=9149.0

Impeccable, merci
Pour être sur (parce que mon anglais ne me permet pas d'être sur), sous Windows, une mise à jour des drivers Intel règle le problème ou il faut tout de même la dernière révision de SFML2.0 ?

22

Discussions générales / Re : Re : Activité de SFML?

« le: Octobre 25, 2012, 02:37:43 pm »

Le bug sur les renderTexture par exemple ?

Oui, comme l'implique la fermeture du ticket correspondant (#101) sur le bug tracker

J'ai bien vu, mais qu'elle était la solution alors ?

23

Discussions générales / Re : Re : Activité de SFML?

« le: Octobre 25, 2012, 02:07:40 pm »

Pour autant que je sache, les bugs avec les cartes Intel ont été reglés.

Par contre il y a de nouveaux bugs, dont la majorité reste certainement à découvrir

Mais globalement il n'y a rien de très gênant. Rien à voir avec SFML 1.6.

Le bug sur les renderTexture par exemple ? Il y a bien eu une solution de contournement proposée (sur la résolution de la RenderTexture), mais elle ne fonctionnait pas dans tous les cas (sans doute parce que le problème était autre aussi...). Et peut-être un bug découvert toujours avec les GPU Intel, possibilité de compiler sans problème, crash à l'exécution, mais pas de problème pour lancer le même programme s'il a été compilé sur une autre machine (et je sais que je dois te faire un rapport là dessus mais la personne à des soucis plus importants pour le moment, donc ce sera pas tout de suite)

24

Discussions générales / Re : Activité de SFML?

« le: Octobre 25, 2012, 12:12:00 pm »

Est-ce que tous les bugs majeurs ont été corrigés dans la dernière rev' ? Il restait le problème avec les GPU Intel c'est aussi reglé ?

25

Graphique / Re : Ecran blanc & loadFromMemory

« le: Octobre 19, 2012, 11:41:42 am »

Ok^^

à l'OP, j'ai mi un '&' devant le auto pour travailler avec des références, mais tu peux l'enlever si tu n'as besoin que de copies (ce qui sur des std::string est toujours suffisant je penses). Si tes chaines ne sont pas trop lourdes ça pourrait même optimiser légèrement tes performances.

26

Graphique / Re : Ecran blanc & loadFromMemory

« le: Octobre 19, 2012, 09:46:08 am »

il y a également l'inférence de type et les range-based for qui pourrait simplifier le code, si je ne me trompe pas :

for (auto& pack : Config::ARCHIVES)
{
   //[...]
}
 

27

Général / Re : Re : Architecture d'un projet SFML

« le: Octobre 18, 2012, 03:57:34 pm »

monTruc.getDrawable

Ca c'est typique d'une mauvaise conception (désolé ).

Une classe doit être pensée en terme de services ("dessine toi") plutôt que de données ("donne moi un truc à dessiner"). C'est beaucoup plus flexible, encapsulé et donc maintenable.

Ce n'est pas que je penses en terme de données, mais je n'aime pas faire hériter mes classes de la SFML, honnêtement je ne le fais jamais car pour moi cela n'a pas de sens. Pour moi un personnage (par exemple) n'EST PAS UN drawable, mais A UNE image que je dois dessiner, etc...

L'utilisateur de la classe n'a en effet pas à savoir quel genre de drawable utilise la classe pour réaliser son dessin ;

je ne comprends pas ce que tu essaies de dire, tu peux développer ?

d'ailleurs tu fais comment pour les entités qui ont besoin de dessiner plusieurs drawables d'un coup ?

Au lieu d'encapsuler dans une seule méthode tous mes appels à draw, j'aurais une méthode pour encapsuler tous mes appels aux getters (d'ailleurs assez particulier une classe à sémantique d'entité (si tu l'as employé dans ce sens) qui posséderait plusieurs drawables, mais ça reste largement imaginable), ce qui revient au même (à part que, si j'ai bien compris, avoir des getters sur ses drawables pour les appeler dans la gameloop, c'est maaal).  Non pour être honnête, surement que dans ce cas là j'aurais écris une méthode draw, mais c'était juste pour dire que dans l'autre sens c'est pas aussi gênant que tu le dis. je redéfinierai draw dans les cas où la phase de conception m'y a conduit inévitablement

Du coup, comme je le disais, une classe dessinable bien conçue aura une fonction draw (que ce soit via sf::Drawable ou à sa propre sauce), et celle-ci doit forcément prendre en paramètre le truc dans lequel elle doit dessiner. Pour moi il n'y a pas vraiment d'autre design qui soit valable, pour cette problématique en particulier.

Donc soit on hérite des drawables (soit à sa sauce, ok), soit notre classe est mal conçue pour cette problématique en particulier (tu veux dire un programme avec plein d'objets à dessiner ?) ? Désolé je fais pas exprès de mal comprendre, mais voilà ce que je comprends.

Parce que si on a un (ou deux) sprite dans notre classe, au lieu d'hériter de drawable,  dans la gameloop on aura sprite.draw(App) au lieu de App.draw(sprite), je trouve pas ça hyper gênant, même pour la maintenabilité..

28

Réseau / Re : Afficher sur un client une image stocké a coté du serveur

« le: Octobre 18, 2012, 03:00:42 pm »

Le client n'aurais aucun de ses fichiers sur son pc et aurais une sorte de téléchargement à chaque changement de map.

ça veut dire aussi qu'à chaque fois qu'on relancerait ton jeu, on aurait une attente pour le téléchargement de cette(ces ?) maps ?

Je ne penses pas que Laurent ai compris ce que tu voulais dire, mais tu ne pourras pas tout garder sur le serveur, il faut bien à un moment que l'image soit sur l'ordinateur où a été lancé le client.

Pour ma part, je fais toujours en sorte que les clients soient aussi lourds que possibles !!
Ce que je veux dire surtout, c'est que je fais tout pour qu'un serveur ne s'occupe que de la communication (une méga-multi paille pour toutes les soupes d'octets qu'il faut aspirer et éjecter d'un client à l'autre).

Pourquoi garder cette image sur le serveur ? le serveur n'en n'a pas besoin. Le client lui, s'il veut avoir quelque chose sur son écran, il en a besoin => ça va côté client.

29

Général / Re : Re : Architecture d'un projet SFML

« le: Octobre 18, 2012, 02:11:21 pm »

Tout ce qui est "drawable" peut-être affiché par la méthode draw de la fenetre, pourquoi refaire un draw ailleurs ?

Si tu dérives de sf::Drawable tu peux faire un window.draw(mon_truc), mais au final tu retombes quand même dans un MonTruc::draw(sf::RenderTarget&, ...), ce n'est qu'une façade syntaxique. Fondamentalement, ça ne change rien au fait que pour dessiner un objet il faut d'une manière ou d'une autre une fonction de ce genre (qui connaisse la render-target) dans tes classes dessinables.

ok, mais justement, il veut implémenter une méthode draw dans toutes ses classes dessinables. On ne peut rien au fait que les fenetre SFML ne peuvent dessiner que des objets de type  sf::drawable, donc soit il fait hériter ses classes de sf::drawable, soit ses classes (dessinables) ont au moins un attribut de ce même type. Dans tous les cas, un simple getter ou un appel direc permet l'appel à ta façade syntaxique window.draw(mon_truc /*ou monTruc.getDrawable*/). Donc pourquoi aurait-il besoin de se trimbaler partout la window ?

C'est comme si je décidais d'utiliser l'API Titanium (pour faire des appli cross-platformes_mobiles avec du JS (horrible)) dans mon code, mais je me retape moi-même tout la couche qui permet d'identifier sur quel OS je suis, alors que j'ai déjà une méthode d'un module qui me permet de le vérifier quand c'est nécessaire de façon beaucoup plus simple ...

Edit : ce que je vais dire peut paraître grossier, mais fondamentalement,  SFML est une grosse façade syntaxique à OpenGL et deux ou trois autres API plus bas niveau. Autant l'utiliser le plus simplement possible, car c'est ça l'objectif au final d'une conception : faire simple. Et je penses que l'OP ou minirop se compliquent la tâche.

30

Général / Re : Architecture d'un projet SFML

« le: Octobre 18, 2012, 09:37:46 am »

Bonjour,

Je me pause quelques questions quand à l'architecture à adopter pour un projet SFML.

Je pensais faire une architecture telle que chacune de mes classes ayant un quelconque comportement implemente une methode Update() et Draw() et la boucle principale du jeu appellerait ces methode en cascade.

La methode Update prendrait en paramètre un entier qui serait le gameTime (en ms).
Or chacune de ces classes aurait besoin de faire des appels à l'objet sf::Window de mon programme.
J'aimerais éviter de "cascader" cet objet dans mes methode Update et Draw de mon jeu.

Quelle serait la meilleur marche à suivre dans mon cas ?


J’espère avoir été suffisamment clair, n'hésitez pas à me demander d'éventuels éclaircissements.

Merci à vous

C'est quelque chose que je ne fais (presque, ça m'est arrivé une fois) jamais pour ma part. Je ne vois pas en quoi tes méthodes draw et surtout update auraient besoin de connaitre ta Window, car pour moi ta méthode draw ne devrait être qu'un getter sur le sprite de ton objet, et ton update ne s'occuper que de la partie "sémantique" de ton objet (i-e les données internes, qu'on affiche pas, genre les coordonnées, l'etat, etc) . Ton problème de conception se situe peut-être là. Tu devrais nous en dire plus sur ton architecture, mais pour ce qui est de "draw" tes objets, je verrai personnellement plus la méthode draw de ta Window être appelée pour tous les objets ayant un comportement quelconque dessinables, et ceci dans ta game loop.

Je penses que SFML a été conçue pour être utilisée dans ce sens, il n'y a qu'à voir la doc et ses nombreux exemples d'utilisation faits par Laurent (et pis même sans voir ce que fait Laurent, en regardant comment est faite SFML). Tout ce qui est "drawable" peut-être affiché par la méthode draw de la fenetre, pourquoi refaire un draw ailleurs ?