1
Discussions générales / Re : SFML & electronique
« le: Juin 13, 2013, 10:47:32 pm »
Chapeau l'artiste 
!
(petit décalage audio vidéo en effet ^^)
!(petit décalage audio vidéo en effet ^^)
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
Pages: [1] 2 Suivante »
2
Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?
« le: Mai 13, 2013, 01:31:43 am »
Autant te mettre au courant tant que c'est chaud, je suis tombé hier (et en fait ça m'a pris plus de 12h de debug, j'y ai passé ma nuit bref j'en passe et des meilleures) sur un bug des compilos g++ et VS (seul clang a corrigé ce bug apparemment), doublé d'une défection de la norme C++11. Autant dire que je n'ai pas rigolé du tout.
Décidément je martyrise ce pauvre sf::Packet, et il y a une chose qu'il sera nécessaire de rajouter afin de rendre le code à la fois plus simple à l'utilisation et surtout moins buggé.
https://github.com/germinolegrand/SFML/commit/7515b960e95d6ebfd759d287f91e2012efdfefd4
Ce commit règle le problème de la sérialisation des enums.
(attention, j'ai bidouillé la classe sf::Packet par ailleurs, seul le contenu de ce commit est exploitable dans la SFML officielle)
--------------------------
Autre question, comment peut-on faire un pull lié au C++11 ? faut-il le nommer d'une façon particulière ? Y a-t-il de la compilation conditionnelle à mettre en œuvre ? Je souhaite réellement pouvoir t'aider dans le passage de la SFML2 au C++11 qui est mon outil de travail le plus précieux
.
Décidément je martyrise ce pauvre sf::Packet, et il y a une chose qu'il sera nécessaire de rajouter afin de rendre le code à la fois plus simple à l'utilisation et surtout moins buggé.
https://github.com/germinolegrand/SFML/commit/7515b960e95d6ebfd759d287f91e2012efdfefd4
Ce commit règle le problème de la sérialisation des enums.
(attention, j'ai bidouillé la classe sf::Packet par ailleurs, seul le contenu de ce commit est exploitable dans la SFML officielle)
--------------------------
Autre question, comment peut-on faire un pull lié au C++11 ? faut-il le nommer d'une façon particulière ? Y a-t-il de la compilation conditionnelle à mettre en œuvre ? Je souhaite réellement pouvoir t'aider dans le passage de la SFML2 au C++11 qui est mon outil de travail le plus précieux
.
3
Graphique / Re : Problème d'affichage de Texture .
« le: Mai 12, 2013, 08:10:34 pm »
Quel IDE utilises-tu ? Si c'est code::blocks, il faut mettre l'image dans le dossier d'exécution qui est par défaut le dossier du .cbp et non du .exe
4
Graphique / Re : Taille d'un sf::Vertex
« le: Mai 11, 2013, 01:15:10 pm »
Bon, je vous suggère d'arrêter là ce troll.
A titre de comparaison, il est plus rapide d'allouer de grandes quantités de mémoire que plein de petites pour une même quantité finale. C'est la raison même d'existence du pooling.
La quantité minimum que peut vous allouer l'OS est d'une page. L'allocation dynamique n'est pas seulement le travail de l'OS, bien plus de votre programme qui va devoir gérer toutes les tailles allouées pour savoir combien il doit libérer.
A titre de comparaison, il est plus rapide d'allouer de grandes quantités de mémoire que plein de petites pour une même quantité finale. C'est la raison même d'existence du pooling.
La quantité minimum que peut vous allouer l'OS est d'une page. L'allocation dynamique n'est pas seulement le travail de l'OS, bien plus de votre programme qui va devoir gérer toutes les tailles allouées pour savoir combien il doit libérer.
5
Général / Encodage des fichiers du code sur github
« le: Mai 06, 2013, 04:09:10 pm »
Bonjour,
Je voudrais savoir quel est l'encodage utilisé par les fichiers de code source situés sur github, car en modifiant une ligne dans un fichier de mon fork, il détecte que la totalité des lignes du fichier ont été remplacées... ce qui est un peu problématique
Je voudrais savoir quel est l'encodage utilisé par les fichiers de code source situés sur github, car en modifiant une ligne dans un fichier de mon fork, il détecte que la totalité des lignes du fichier ont été remplacées... ce qui est un peu problématique
6
Général / Re : [SFML2] Compilation avec CMake
« le: Mai 06, 2013, 03:58:23 pm »
Je précise au cas où, je sais que quand les versions 4.7 successives sont arrivées j'ai dû recompiler entièrement ma chaîne de compile pour chaque version, puisque le moindre mélange provoquait des problèmes de link/dll. (avec C++11)
7
Suggestions de nouvelles fonctionnalités / Re : Gestion des dossiers
« le: Mai 06, 2013, 03:55:32 pm »
Vouloir faire un projet complet uniquement avec la SFML me semble tout à fait réaliste (et réalisé un certain nombre de fois d'ailleurs). En revanche la gestion des dossiers et autres filesystems regarde plutôt le comité de standardisation du C++ qui planche d'ailleurs là dessus pour C++1y.
8
Général / Re : [SFML2] Compilation avec CMake
« le: Mai 06, 2013, 03:29:43 pm »
Il y a une incompatibilité au niveau de l'ABI de g++4.7.1, réparée avec la 4.7.2, les trois versions 4.7.0, 4.7.1, et 4.7.2 sont donc incompatibles entre elles ce me semble.
9
Discussions générales / Re : SFML 2 est là avec son nouveau site web
« le: Mai 06, 2013, 01:12:53 pm »
C'est exactement ça 
10
Discussions générales / Re : SFML 2 est là avec son nouveau site web
« le: Mai 06, 2013, 12:32:47 pm »
Toute la chaîne de compilation de l'équipe est basée sur C::B qui nous assure la portabilité de l'environnement de compilation en plus de la portabilité du code ^^ (j'arrive sur une plateforme, je télécharge c::b, cmake, bazaar, git (pour la SFML), j'appuie sur le bouton compiler de c::b hop tout fonctionne j'ai la SFML qui compile, le moteur qui compile, un jeu qui tourne ^^).
Le problème majeur que j'ai rencontré est que cmake ne sais pas générer un vrai projet .cbp, contrairement à VS il me semble. Il ne peut générer qu'un squelette qui se contente d'appeler un script de cmake qui lui-même appelle le compilo.
De plus cmake n'est pas capable de générer deux cibles à la fois : si on veut passer de debug à release (et inversement), il faut faire un cleanup complet des fichiers et rappeler la configuration/génération de cmake.
Avec un peu d'huile de coude et de rafistolage, je suis bien arrivé à avoir un projet c::b qui me permette de travailler... mais c'est grâce à c::b (qui a le mérite d'être très modulable il faut le lui reconnaître) et pas à cmake qui ne fait que me faire perdre un temps précieux. Il est amusant de noter que C::B manipule bien les .cmake en leur offrant même une coloration syntaxique adaptée
Le problème majeur que j'ai rencontré est que cmake ne sais pas générer un vrai projet .cbp, contrairement à VS il me semble. Il ne peut générer qu'un squelette qui se contente d'appeler un script de cmake qui lui-même appelle le compilo.
De plus cmake n'est pas capable de générer deux cibles à la fois : si on veut passer de debug à release (et inversement), il faut faire un cleanup complet des fichiers et rappeler la configuration/génération de cmake.
Avec un peu d'huile de coude et de rafistolage, je suis bien arrivé à avoir un projet c::b qui me permette de travailler... mais c'est grâce à c::b (qui a le mérite d'être très modulable il faut le lui reconnaître) et pas à cmake qui ne fait que me faire perdre un temps précieux. Il est amusant de noter que C::B manipule bien les .cmake en leur offrant même une coloration syntaxique adaptée
11
Discussions générales / Re : SFML 2 est là avec son nouveau site web
« le: Mai 06, 2013, 12:02:14 pm »
Eheh, je n'avais pas encore eu le temps de passer te féliciter, voilà qui est chose faite !
Je veille à ce que la SFML soit largement plébiscitée sur developpez.com ^^
La seule chose qui m'a fait souffrir dans l'histoire c'est cmake
autant quand on veut juste faire un build ça va, autant quand on veut avoir un projet .cbp qui permette de travailler sur la SFML elle-même, c'est vraiment la galère... Comment tu gères ça Laurent, je suppose qu'avec VS cmake marche mieux ?
Je veille à ce que la SFML soit largement plébiscitée sur developpez.com ^^
La seule chose qui m'a fait souffrir dans l'histoire c'est cmake
autant quand on veut juste faire un build ça va, autant quand on veut avoir un projet .cbp qui permette de travailler sur la SFML elle-même, c'est vraiment la galère... Comment tu gères ça Laurent, je suppose qu'avec VS cmake marche mieux ?
12
Audio / Re : Trop de threads tue le thread.
« le: Mai 03, 2013, 03:09:29 pm »
Je ferai des investigations, pas trop le choix de toute façon.
Ce sont surtout les threads qui se lancent et s'arrêtent en permanence qui m'intriguent (et surtout risquent d'avoir un mauvais impact sur les perfs).
(Désolé pour le temps de réponse, oublié de cocher notif par email)
Ce sont surtout les threads qui se lancent et s'arrêtent en permanence qui m'intriguent (et surtout risquent d'avoir un mauvais impact sur les perfs).
(Désolé pour le temps de réponse, oublié de cocher notif par email)
13
Audio / Trop de threads tue le thread.
« le: Avril 19, 2013, 02:32:02 am »
Quand le module Audio est initialisé, il crée au moins 10 threads o_O !
Y-a-t-il une raison à cela ?
Dans le code je n'ai pas vu de launch en dehors des endroits où la musique est jouée (c'est d'ailleurs bien piquant le stop+launch dans le setPlayingOffset x) ).
D'autant que sur les 10 threads, 2 d'entre eux se suppriment et se relancent en permanence... ce qui n'est pas pour arranger les choses.
Est-ce OpenAL qui crée tous ces threads ?
Y-a-t-il une raison à cela ?
Dans le code je n'ai pas vu de launch en dehors des endroits où la musique est jouée (c'est d'ailleurs bien piquant le stop+launch dans le setPlayingOffset x) ).
D'autant que sur les 10 threads, 2 d'entre eux se suppriment et se relancent en permanence... ce qui n'est pas pour arranger les choses.
Est-ce OpenAL qui crée tous ces threads ?
14
Suggestions de nouvelles fonctionnalités / Re : sf::Packet proposer une 2e interface non modifiante
« le: Août 30, 2012, 12:49:06 pm »
En effet #112
sf::Packet has no Seek function for random access
sf::Packet has no Seek function for random access
15
Suggestions de nouvelles fonctionnalités / sf::Packet proposer une 2e interface non modifiante
« le: Août 27, 2012, 12:42:36 pm »
Actuellement, lorsqu'on souhaite extraire une donnée de sf::Packet, il n'est plus possible de lire cette donnée déjà extraite. La seule façon de le faire est d'utiliser getData et de faire quelques casts horribles qui ne devraient pas avoir lieu d'être puisqu'il faut pour cela connaître la construction interne de sf::Packet pour s'assurer de son fonctionnement. Si je veux récupérer le premier char :
.
Je propose d'ajouter une fonction template :
Ou alors mieux : proposer des fonctions pour sauvegarder une position dans un sf::Packet pour l'y faire revenir plus tard (en clair on sauvegarde m_readPos). Ainsi que les positions statiques définies à l'avance : begin et end.
La 1e solution n'est qu'une solution vite fait, tandis que la 2e s'inscrit plus dans la logique des flux (voir std::fstream et compagnie).
char data = *reinterpret_cast<const char*>(packet.getData());
C'est juste moche .Je propose d'ajouter une fonction template :
template <class T>
void Packet::get(T &data)
{
*this >> data;
m_readPos -= sizeof(data);
}
void Packet::get(T &data)
{
*this >> data;
m_readPos -= sizeof(data);
}
Ou alors mieux : proposer des fonctions pour sauvegarder une position dans un sf::Packet pour l'y faire revenir plus tard (en clair on sauvegarde m_readPos). Ainsi que les positions statiques définies à l'avance : begin et end.
La 1e solution n'est qu'une solution vite fait, tandis que la 2e s'inscrit plus dans la logique des flux (voir std::fstream et compagnie).
Pages: [1] 2 Suivante »