Messages

16

Projets SFML / Re : Re : Framework

« le: Décembre 11, 2013, 07:44:52 pm »

Ton code utilise les std::function du c++11 non ?

Oui. Mais il y a std::tr1::function depuis le TR1 (2005).

Pour chaque fonctions rajoutées, il faut redéfinir un nouveau pointeur de fonction, en plus de redéfinir la fonction.

Tu parles de quelles fonctions et pointeurs ? Il faut seulement en définir si les clés (thor::ResourceKey) existantes ne suffisent pas.

-Dans ton cas la ressource se détruit si plus rien ne la référence si j'ai bien compris le système des shared pointeurs.

Il y a deux strategies : L'un est comme tu dis, l'autre garde les ressources jusqu'à ce que tu les enlève (ou le cache et le dernier shared_ptr se détruisent).

Bref c'est chouette, c'est plus sûr et on ne risque pas d’accéder à une ressource qui n'existe plus mais ce n'est pas vraiment nécessaire avec le principe RAII comme tu dis :
J'ai toujours appris à programmer sans utiliser des shared pointeurs et en gérant la mémoire moi même.

Tu as raison, mon système de ressources est plutôt compliqué, pour la plupart de cas un approche plus simple suffit.

(car les shared pointeurs ont plusieurs défaut : on ne peut pas les utiliser dans une classe copiable, notamment, et ni dans un vector, un array, etc...)

Ce n'est pas 100% vrai : Tu peux les utiliser dans des classes copiables et dans des containers, mais il faut savoir que l'objet référencé n'est pas copié.

Si tu veux que le pointeur copie aussi l'objét, tu peux utiliser aurora::CopiedPtr, une autre classe que j'ai développée.

De ce fait j'ai toujours opté pour le système qui se rapproche de java : ArrayList maList<?> ou le ? réprésente n'importe quel type tout comme le pointeur sur void du c++.

void* n'est pas "typage-sûr", tu ne sais pas ce qui se cache derrière. Et tu ne peux rien faire sans savoir. C'est à cause de ça qu'il y a des téchniques très elegantes, comme type erasure.

De plus j'ai vu que tu utilises les shared pointeurs et unique pointeurs du c++11, qui me pose certains problèmes de compatibilité suivants les différents compilateurs.

Il y a std::tr1::shared_ptr qui existe depuis 2005, et std::auto_ptr depuis 1998. Malgré qu'il faut être prudent en utilisant auto_ptr, c'est beaucoup mieux que gérér la mêmoire manuellement. En plus, une petite classe smart-pointeur comme boost::scoped_ptr est écrit dans une quart d'heure.

Si il se trompe dans le nom de l'alias certes ça plantera à l'exécution, mais au pire y'a la fonction rechercher/remplacer je pense que ça ira plus vite que de devoir déclarer tous pleins de variables de type key ou autre pour récupérer une texture.

Ca depend. Récemment j'ai écrit un système de scripte Lua, où tout est géré avec des strings. C'est plus dynamiques, mais j'ai déjà eu pleine des erreurs parce que les strings n'ont pas été correctes, et j'ai dû debugger quelque temps. Si tu as un projet moyen où tu n'as pas besoin de la fléxibilité des identifiers dynamiques, les enums peuvent valoir la peine.

Sinon je me demande si en c++ il y a moyen de lancer une exception à la compilation

static_assert

Mais naturellement, il n'est pas possible de vérifier les strings pendant la compilation, alors ça ne t'aide pas.

17

Projets SFML / Re : Framework

« le: Décembre 11, 2013, 03:47:48 pm »

Quelques idées:

• N'utilise pas de singletons ni des variables globales/statiques. Même s'ils paraissent utiles, ils ont beaucoup de problèmes. Dans une architecture plus grande et modulaire, c'est exactement ce que tu ne veux pas
• Suis le principle RAII. Il ne faut pas utiliser new ou delete sans encapsulation. Et c'est mieux si l'utilisateur n'est pas obligé d'appeler des méthodes comme deleteResourceByAlias() à la fin.
• Comme Lo-X a déjà dit, le livre utilise les enums parce qu'ils offrent la sûreté de typage au temps de compiler -- si tu utilise un enumerateur qui n'est pas correcte, le compilateur te donne un erreur. Au contraire, avec strings tu as des bugs, et il faut adapter tout les endroits (et il y en aura beaucoup plus que 1, parce que le alias est la seule possibilité pour accèsser les resources dans ton système).
• Considère les règles de possession (c'est beaucoup plus simple avec RAII).
• Avoir void* ou boost::any est très souvent un erreur de design. Avec le polymorphisme dynamique, tu n'as pas besoin de différencer les cas.

Tu peux aussi regarder comme j'ai resolu quelques problems avec la gestion de resources en Thor (tutoriel, documentation). C'est un peu plus compliqué que ce que tu veux faire, mais ça peut quand même aider. Par exemple, thor::MultiResourceCache est capable de mémorizer plusieurs types de resources -- sans void* ou boost::any. Le principle s'appelle "type erasure".

18

Discussions générales / Re : Re : SFML Game Development -- Un livre sur SFML

« le: Décembre 08, 2013, 02:06:30 pm »

Si on achète le livre, peut on également avoir accès gratuitement à la version numérique ou c'est un achat à part ?

Oui, tu reçois aussi le e-book si tu achètes le livre (sur la site Packt, tu verra "Print + free eBook + free PacktLib access to the book").

Lo-X à déjà repondu aux autres questions

19

Projets SFML / Re : Projet d'extension de SFML. (SFML 3D)

« le: Novembre 21, 2013, 10:22:07 pm »

C'est un projet intéressant. Il y a quelque temps qu'un autre utilisateur a commencé un projet pareil, sf3d. Malhereusement cela n'est plus developpé activement, mais il contient déjà beaucoup de fonctionnalité. Laisse-toi inspirer...

Si tu lis le fil de sf3d, tu vais voir qu'il y a des autres gens qui sont aussi intéressés dans une bibliothèque 3D -- peut-être vous pouvez collaborer?

Et oui, un nom plus original ne serait pas mal

20

Discussions générales / Re : SFML Game Development -- Un livre sur SFML

« le: Novembre 19, 2013, 06:46:18 pm »

Pour ce qui est de l'emplacement, je sais plus où j'avais vus, mais il me semble que c'était un vector déclarer de taille fixe. Cette taille étant la taille d'une enum. Dans ce cas, un array aurais été préférable.

Pas nécessairement. std::array est plus vite parce qu'il n'a pas besoin d'allocation, mais il a le désavantage qu'il faut connaître la taille à la déclaration, que l'objet peut utiliser le mémoire du stack qui est limité, et que l'opération move est lente et pas "exception-safe". D'autre part, std::vector est problematique s'il est contenu de beaucoup des petits objets, alors l'allocation et le mémoire ne valent pas la peine.

Dans beaucoup des cas, particulièrement avec seulement douzaines des elements, il n'y a pas de différence importante.

Je sais que en C, les enum commencent pas forcément à 0, sauf si on spécifie explicitement (ça dépend des compilot). Pour le C++, je n'ai aucune idée de si la norme définie que les enum commencent à 0.

Oui, elle est définie comme ça, donc le = 0 est superflu et pas habituel.

Et je doute fort que c'était différent en C. Selon la norme C89 (c'est la seule version que j'ai trouve maintenant):

If the first enumerator has no = , the value of its enumeration constant is 0. Each subsequent enumerator with no = defines its enumeration constant as the value of the constant expression obtained by adding 1 to the value of the previous enumeration constant.

21

Discussions générales / Re : SFML Game Development -- Un livre sur SFML

« le: Novembre 17, 2013, 11:06:01 am »

Merci pour le feedback!

Par exemple, une des erreurs qui revient le plus souvent est la mauvaises utilisations des containers de la STL. Très souvent std::vector<T>  est utilisé alors qu'il y a bien plus adapté à la situation (array, list, stack ...).

On utilise beaucoup des containers spécialisés: vector, deque, list, array, queue, set, map. Mais en général, std::vector est le "défaut", parce qu'il se comporte bien dans la plupart des situations. Où est-ce que tu penses qu'il serait mieux d'utiliser un container différent?

Un autre point que j'ai trouvé étrange lors de la lecture de ce livre, est que std::move est utilisé dans les premiers chapitres (abordant donc les rvalue-references) mais que les «move constructors» ne sont jamais abordés

Il ne faut pas définir les constructeurs move si les objets (comme std::unique_ptr) sont déjà "movables". Aussi les rvalue-references, notre code ne les contient pas. Nous appliquons la sémantique move, mais nous évitons de définir des types movables (les compilateurs sont capables de les définir implicitement).

Le dernier points que je détaillerais n'est présent qu'une seul fois dans le code. Une surcharge est faite pour la méthode «load» de «ResourceHolder», dupliquant une partie du code (rompant les concepts  définies au début du livre prohibant la duplication). D’après moi, l'utilisation de «template variadiques» couplé à std::forward aurait été bien plus judicieux, et aurais également permis d'aborder ces ajout au C++ de façon simple et efficace.

Oui, mais comme nous avons expliqué au début, nous avons fait des compromis pour souténir des compilateurs comme VS 2010. Dans un autre contexte (state stack), nous mentionnons les variadic templates.

22

Discussions générales / Re : Re : La 3D.

« le: Octobre 27, 2013, 07:15:03 pm »

Toutes les bibliothèques 3D ont un graphe de scène, c'est presque le standard. Multi-threading depend surtout de l'application, il n'y a pas beaucoup de sens de synchroniser des choses quand tu ne les utilises pas. Irrlicht offre la détection de collision et de la physique basique. Si tu as besoin de la fonctionnalité plus complexe, il faut utiliser une bibliothèque physique de toute façon, tu ne peux pas écrire tout le code toi-même. Mais c'est aussi vrai qu'Irrlicht est déjà un peu âgé, particulièrement le code C++ n'est pas très moderne.

Je ne dis pas qu'il faut developer avec Irrlicht, mais il paraît que tu ne l'a pas assez utilisé pour connaître toutes ses possibilités. Et peut-être tu sous-estimes un peu le travail necessaire pour la graphique 3D, car c'est beaucoup plus complèxe que 2D: Matériels, terrains, lumières, ombres, brouillard, shaders, animations, particules, modèles 3D, algèbre linéaire, ... Voici toutes les choses qu'Irrlicht déjà offre. Avec OpenGL, tu as une éternité pour implementer même une partie.

23

Discussions générales / Re : Re : La 3D.

« le: Octobre 26, 2013, 01:06:08 pm »

J'ai eu des problèmes pour comprendre le fonctionnement de Irrlicht et Ogre, je n'ai pas trouvé d'exemple, ni de documentation ni de tutoriels vraiment bien fait comme pour ici, bref...

Tu as lu ceux d'Irrlicht? Je ne trouve pas qu'il sont mal faites. Pour Ogre, c'est une différente chose...

Documentation: http://irrlicht.sourceforge.net/docu
Des tutoriels: http://irrlicht.sourceforge.net/tutorials

Si tu as besoin de plus de flexibilité qu'avec une bibliothèque, OpenGL est une bonne idée, mais je ne comprends pas pourquoi tu demandes d'avoir 3D en SFML? Tu aurais exactement le même problème... Irrlicht est une abstraction de OpenGL (et de DirectX, si tu veux) pareille à SFML, mais il offre aussi des choses au niveau plus haut. Améliorer les performances d'une bibliothèque qui existe depuis plusieurs ans n'est pas toujours simple, particulièrement quand tu commences à dessiner des scènes complètes. C'est aussi la question si tu aimerais plutôt comprendre les téchniques bas-niveaux et écrire ton propre moteur, ou developper un jeu

24

Discussions générales / Re : La 3D.

« le: Octobre 24, 2013, 05:58:13 pm »

Il y a des bibliothèques qui sont spécialisées pour la graphique 3D, par exemple Irrlicht.

25

Projets SFML / [Zloxx 2.2] Version Linux, nouveaux graphiques

« le: Octobre 01, 2013, 05:56:10 pm »

Zloxx v2.2 publié



[-> Page du projet]

Zloxx II est maintenant disponible pour Linux. J'ai amelioré les graphiques et quelques autres choses (les détails sont écrites dans le fil de discussion anglais).

26

Discussions générales / Re : SFML Game Development -- Un livre sur SFML

« le: Juillet 18, 2013, 07:20:55 pm »

Le code du livre est maintenant disponible sur GitHub. Il est accompagné par une license libre (qui interdit seulement l'utilisation commerciale). N'hésitez pas de développer vos extensions
https://github.com/SFML/SFML-Game-Development-Book

27

Général / Re : [Résolu] Problème système d'animation

« le: Juillet 04, 2013, 05:50:39 pm »

A propos, les noms qui commencent avec "_" et un lettre majuscule (comme _Frame) sont réservés pour le compiler et la bibliothèque standard. Par exemple, un header qui definit un tel macro peut introduire des bugs très difficiles à trouver.

Pour les membres, tu peux juste utiliser "mAnim", "m_Anim", "m_anim" ou "anim".

28

Suggestions de nouvelles fonctionnalités / Re : Définir un ordre d'affichage par vertex.

« le: Juillet 04, 2013, 01:55:08 pm »

Est-ce que trier les objets dans une liste avant dessiner n'est pas une option? Ca serait beaucoup plus simple, et tu n'aurais pas besoin de modifier SFML.

A propos, les ordinateurs qui n'offrent pas GLSL sont très anciens (une décennie et plus).

29

Suggestions de nouvelles fonctionnalités / Re : Définir un ordre d'affichage par vertex.

« le: Juillet 04, 2013, 11:49:29 am »

En fait ce n'est pas si facile, par exemple il y a des problèmes avec la composante alpha. Cherche les fils de discussion anglais

30

Suggestions de nouvelles fonctionnalités / Re : Définir un ordre d'affichage par vertex.

« le: Juillet 04, 2013, 11:22:13 am »

Ce n'est pas directement possible, tu devrais dessiner les vertexes dans l'ordre que tu veux. Donc il faut utiliser plusieurs vertex arrays.