Discussion :

[Invité]

Salut,
ODFAEG (Opensource Developpement Framework Adapted For Every Game)

je suis actuellement entrain de développez un moteur de jeux opensource ainsi que un petit jeux comme démo.

je recherche d'éventuels personnes pour m'aider un peu. (Car le travail pour moi tout seul c'est un peu beaucoup)
je n'ai pas beaucoup de moyens non plus donc je dois faire avec ce que j'ai mais je ne parlerai pas de ma vie privé ici.

Je veux que le framework soit le plus simple possible aussi bien au niveau interne que utilisation (vous verrez d'ailleurs qu'il y a beaucoup de classes mais peu de fonctionnalités), compatible avec le plus de plateformes possible et le plus générique possible c'est à dire "templatisé" un maximum afin d'éviter les contraintes due à l'héritage et des algorithmes qui fonctionne aussi bien en 2D que en 3D (le projet est similaire à unity mais je ne veux pas devoir dépendre d'une interface graphique)
Le projet vise à supporté toutes les versions d'opengl, mais pour le moment je ne peux utilsier l'opengl moderne pour la démo car ma platforme ne le supporte pas.
J'ai donc du faire recours à des techniques pour un rendu rapide avec les anciennes versions de opengl.

Le moteur de jeux est déjà bien avancé même si il me reste encore quelques fonctionnalités évoluées au niveau du graphismes à implémenter, voici une liste de tout ce qui est déjà implémenter et des idées de ce qui pourrait être implémenté afin d'améliorer le moteur.
Le moteur utilise les dépendances suivantes pour le moment il ne fonctionne qu'en linkage statique mais je ferai aussi un linkage dynamique sur la fin, et il est écrit entièrement en c++11. (Donc votre compilateur doit supporté le c++11)

Dépendances utilisées : SFML 2.1 (en espérant que la version 3 sorte assez vite pour le portage sur android et la gestio multi écran), openssl pour la cryptographie (obligé à cause de tout les bots qui parcours le net) et je pense que c'est tout, je ne veux pas utiliser de trop grosses dépendances.
Il vous faut donc installé SFML (ainsi que tout ses dépendances) et openssl pour pouvoir compiler.
Au pire j'ai tout expliqué dans un tutoriel sur le github : (Le développement se fera sur la plateforme git-hub :

https://github.com/Lolilolight/ODFAEG

Ce qui est implémenté : (Il y a plusieurs modules)

Le module core : comprends toutes les fonctionnalités de bases c'est à dire :

-Un système de gestion des ressources externes.
-Un système de gestion de commandes.
-Un système de gestion des states.
-Et pleins de classes utilitaires utilisée par les autres modules du framework.
-Un système de sérialisation de données utilisant les flux du c++. (Similaire à boost mais sans le système de registration, je préfère que le framework soit templatisé un maximum et donc que ça soit le développeur qui décide du type de l'objet et qui décide d'appliquer le cast adéquat lors des actions à effectuer sur les entités dérivée et non pas le framework qui décide)

Le module Graphique :

Se divise en 3 sous modules :

Le sous module de base :

-L'affichage de forme de base. (2D)
-Un système de composant et un gestionnaire de composants. (Composant de rendu uniquement, sorte de pipeline qui gère la transparence, génère le depthbuffer, la normal map, le framebuffer, etc..., peut être utiliser pour faire du rendu multi-pass également.)
-Le module graphique de SFML que j'ai modifié pour afficher des sommets en 3D, optimiser l'affichage à l'aide de VBO et regrouper toutes les faces utilisant la même texture ensemble pour éviter les appels trop nombreux à glBindTexture.
Le module graphique doit pouvoir aussi choisir la méthode de rendu en fonction de la version d'opengl supportée par la plateforme.

Le module 2D qui utilise le module de base :

-Un système d'entités. (Avec entités parent et enfants, transformations, etc...)
-Un gestionnaire d'entités.
-Un moteur de lumière et d'ombrage.
-Les animations.
-Un gestionnaire d'entités.


Le module 3D qui utilise aussi le module de base n'est pas encore implémenté.

Le module graphique est le plus conséquent et le plus compliqué des modules.

Le module physique et méthématique :

-Un système de gestion des collisions. (hiérarchie de volumes englobants)
-Un système de gestion des particules.
-Calcul de position sur une courbe en fonction du temps.
-Rayon pour sélection d'objets.
-Etc...

Le moteur réseau :

-Un système de communication en mode TCP et UDP de manière assynchrone et sécurisé avec une liste pour la réception de messages.
-Possède une liste d'utilsateurs égalements et garde une trace des utilisateurs qui ont envoyé une requête côté serveur.
-Calcule du ping moyen pour chaque utilisateur.(Côté serveur)

Je suis actuellement entrain de testé ça avec 3 projets : le 1et n'utilise pas le module réseau.
Le second projet est un serveur.
Le 3ème est le client.

-Le moteur de son :
Gère le chargement des musiques et des bruits, et également la spartialisation du son (la 4D) grâce à SFML.

Voici actuellement ce que je suis capable de faire avec le framework :

Le 1er vidéo concerne la démo hors réseau et la second en réseau (je n'ai pas mis les lumières en réseau car je dois justement finir la sérialisation pour toutes les classes du framework pour simplifier le transfert des entités plus complexes du serveur vers le client.)

Maintenant je vais terminé par vous parler des fonctionnalités qu'il reste à implémenter :

-La génération de terrains en 3D.
-Le chargement de modèle 3D à partir de fichiers externe. (Je ne compte utiliser que des fichiers .obj car c'est le plus simple à charger et les animations je peux gérer ça facilement avec le framework en faisant une interpolation linéaire)
-Les animations en 3D. (Avec interpolation)
-L'affichage de formes simples en 3D.
-Le moteur d'éclairage et d'ombres en 3D.
-Le gestionnaire d'entités pour les entités en 3D.
-Un driver MySQL.
-Des composants GUI en plus des composants de rendus.
-Et pourquoi pas des composants spécialisé pour le développements de jeux par navigateur.

Voilà donc en gros j'en suis à un peu plus que la moitié, mais je compte faire une pause et m'amuser un peu avec le framework là en créant un jeux en 2D et ensuite je passerai à l'implémentation de la 3D.

Si vous êtes partant pour coder ne fuse qu'une fonctionnalité ou bien pour corriger un bug ou encore si vous penser pouvoir optimiser le code, n'hésiter pas à m'en faire part.

Voilà merci d'avance pour votre contribution.

La majorité des fonctionnalités contenue dans le framework lui même ont été implémentée par moi seul, et une minor partie est du code source que j'ai repris tel quel.

[Nico65]

c'est pas toi qui parlait sur le forum SFML de le rendre "compatible 3D", ou je confond ?
en tout cas, un projet intéressant qui a l'air bien parti
si je trouve 5 min je téléchargerais le projet Git...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
D:\NCHA\ODFAEG\src\odfaeg\Core\erreur.cpp|3|warning: 'odfaeg::Erreur::Erreur(int, const string&, int)' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]|
D:\NCHA\ODFAEG\src\odfaeg\Core\erreur.cpp|7|warning: 'virtual const char* odfaeg::Erreur::what() const' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]|
D:\NCHA\ODFAEG\src\odfaeg\Core\erreur.cpp|12|warning: 'int odfaeg::Erreur::getNiveau() const' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]|
D:\NCHA\ODFAEG\src\odfaeg\Core\erreur.cpp|17|warning: 'virtual odfaeg::Erreur::~Erreur()' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]|
D:\NCHA\ODFAEG\src\odfaeg\Core\resourceSystem.cpp|3|warning: 'odfaeg::ResourceSystem::cache' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]|
D:\NCHA\ODFAEG\src\odfaeg\Core\resourceSystem.cpp|3|error: definition of static data member 'odfaeg::ResourceSystem::cache' of dllimport'd class|
D:\NCHA\ODFAEG\src\odfaeg\Core\resourceSystem.cpp|4|warning: 'static odfaeg::ResourceCache& odfaeg::ResourceSystem::getCache()' redeclared without dllimport attribute after being referenced with dll linkage [enabled by default]|
||=== Build finished: 1 errors, 6 warnings (0 minutes, 2 seconds) ===|

essayé avec le compilateur par défaut de Code::Blocks et TDM, pareil

[jean_kevin_musclor]

omg le boulot de malade Oo
impressionnant...

dommage je suis pas compétent pour te suivre dans l'aventure mes notions d'opengl n'ont pas dépassé le stade d'afficher un rectangle....

[Invité]

Re,

L'option shared ne fonctionne pas encore, je dois encore configurer la lib pour la rendre fonctionnelle. (Il faut donc la décochée pour que ça compile)

Entre temps j'ai amélioré le système de sérialisation. (grâce à l'aide de certains membres sur ce site)
Je viens de mettre à jour le git-hub.
Et je vais de ce pas améliorer le système de détection de collisions entre les volumes englobant avec un double dispatch.

Oui c'est bien moi qui parlais de rendre SFML compatible pour la 3D car je trouve cette librairie intéressante.

Ca a été en effet un boulot de malade car je voulais rendre ça le plus générique possible pour une adaptation plus facile du code avec la 3D par la suite. (J'ai du revoir donc plusieurs fois le design de la librairie)

Je pense que je vais continuer en ajoutant des ennemis sur la carte pour voir ce que je peux faire au niveau gameplay déjà et ensuite j'attaquerai l'affichage d'objet 3D.

Je recherche en effet des personnes très expérimentées, car, ce framework n'est pas une mince affaire. (Je l'ai fais au départ pour apprendre mais maintenant (après plusieurs années) je voudrais en faire une vraie librairie connue comme SFML.

Là ou j'aurai besoin d'aide aussi c'est pour le site web. (A vrai dire il ne me reste pratiquement plus que ça à faire ainsi que les graphismes pour les démos et quelque bidouilles au niveau du code source)

La version 2 (version actuelle de la librairie) ne contiendra pas d'algorithme de génération/chargement et gestion d'objet 3D, ceci est réservée pour la dernière version.

Mais on peut déjà néanmoins afficher des objets 3D simple avec le framework et choisir la perspective.
Bref il me faudra un long tutoriel rien que sur la caméra car un peux faire pas mal de choses.

Mon but étant d'adapter le framework pour qu'il soit utile pour créer un maximum de jeux sans devoir passer dépendre d'une interface graphique.

J'attends donc que les codeurs aient une bonne expériences du c++11, qu'ils savent coder une librairie de manière la plus générique possible, et qu'ils soient soigneux au niveau du code au cas ou cette librairie serait utilisée par pleins de gens.

Pour le webmaster, un site web similaire à celui de SFML me conviendrais.

[Invité]

git mit à jour, j'ai mis au point une interface pour gérer les collisions entre différentes hiérarchie de volumes englobants.

Je n'ai plus qu'à essayer de simplifier le transfert de la map en réseau à l'aide de mon système de sérialisation maintenant ensuite j'attaque l'IA et le gameplay de mon jeux en 2D iso.

Ca va être fun.

Pour le transfert d'image par contre ça ne semble pas être, très top. (je me retrouve avec un carré blanc à la désérialisation)

[Invité]

J'ai oublié de précisé, comme proposition pour une nouvelle fonctionnalité, l'affichage de texte en 3D.

Je pense que combiner mon système de delegate avec le mécanisme de la classe serializer qui me permet de simuler l'appel d'une fonction virtuelle template afin de le faire pour n'importe quel type de fonction (et pas seulement la fonction serialize) serait bien je pense que plus tard je vais me pencher là dessus.

[Invité]

J'ai changé le système de sérialisation afin de régler les problèmes avec les includes et les forward déclarations.

De plus j'ai fait un système de réflexion pour ne plus devoir modifier la bibliothèque.

Par contre il y a plus de macro à définir. (Car il faut enregistrer une clé dans le fichier de la classe de base, une dans les fichiers.h de chaque type dérivé, et ensuite, dans le main pour enregistrer chaque type et chaque fonction pour chaque type et pour chaque spécialisation de template possible dans la factory.)
Se système permet entre autre, d'appeler des fonctions template virtuelles. (En enregistrant pour chaque types, une spécialisation de la fonction template, ensuite, il suffit de passer la signature de la fonction et un pointeur sur le type de l'objet, la factory appellera automatiquement la bonne fonction template spécialisée sur le type dynamique de l'objet.

Le système de réflexion consiste à enregistrer dans une factory, des id et des types, ainsi que des fonctions pour chacun de ses types, elle recherche ensuite le type dynamique de l'objet et la signature de la fonction template spécialisée lors de l'appel de la fonction à l'exécution.

Les types sont des types dérivés d'une classe de base bien entendu.

Vous pouvez toujours consulter mon devblog pour plus d'informations sur mes essais pour rendre le framework le mieux possible :

http://lolilolightdevblog.wordpress.com/

Si vous avez des meilleurs solutions à proposer je suis toujours preneur.

Mais ici ce dont j'ai besoin c'est de tout sérialiser dans un flux afin d'envoyer la map sur le réseau avec moins de ligne de code.

Je mettrai le git-hub à jour prochainement. (Car l'ancien système n'étais pas pratique)

[Invité]

J'ai modifier les macros dans le fichier serialization.h et j'ai rajouté une macro pour éviter de devoir utiliser plusieurs macro dans le main :

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
#define REGISTER_DERIVED(ID, BASE, TYPE) \
inline BASE* create##ID() { \
    return new TYPE(); \
}
#define REGISTER_TYPE(ID, BASE, TYPE) \
{ \
odfaeg::BaseFact<BASE>::register_type(typeid(TYPE).name(), &create##ID); \
}
#define REGISTER_FUNC(ID, funcName, FID, BASE, TYPE, args...) \
{ \
REGISTER_TYPE(ID, BASE, TYPE) \
odfaeg::FastDelegate<void> delegate##ID##funcName##FID (&TYPE::vt##funcName, args); \
odfaeg::BaseFact<BASE>::register_function(typeid(TYPE).name(), #funcName, #FID, delegate##ID##funcName##FID); \
}
#define CALL_FUNC(BASE, funcName, funcArgs, object, args...) \
{ \
odfaeg::BaseFact<BASE>::callFunction(typeid(*object).name(), funcName, funcArgs, object, args...); \
}
#define EXPORT_CLASS_GUID(ID, BASE, TYPE) \
REGISTER_TYPE(ID, BASE, TYPE) \
{ \
std::ostringstream out##ID; \
std::istringstream in##ID; \
odfaeg::OTextArchive *outa##ID = new odfaeg::OTextArchive(out##ID); \
odfaeg::ITextArchive *ina##ID = new odfaeg::ITextArchive(in##ID); \
TYPE* derived##ID = new TYPE(); \
REGISTER_FUNC(ID, serialize, OTextArchive, BASE, TYPE, derived##ID, outa##ID) \
REGISTER_FUNC(ID, serialize, ITextArchive, BASE, TYPE, derived##ID, ina##ID) \
delete outa##ID; \
delete ina##ID; \
delete derived##ID; \
}

Dès à présent l'appel d'une seule macro dans le main suffit.

EXPORT_CLASS_GUID(BoundingBox, odfaeg::BoundingVolume, odfaeg::BoundingBox)
EXPORT_CLASS_GUID(BoundingSphere, odfaeg::BoundingVolume, odfaeg::BoundingSphere)

[yetimothee]

Voici ce qui me frappe (en toute franchise, j’espère que tu comprendras !) :
- tes commits git sont dégueulasses, ça ne sert à rien d'utiliser git si c'est pour faire des commits de 15 fichiers à chaque fois. Pour moi git c'est bien quand tu versionne de manière atomique. Là ça n'est pas du tout le cas, à quoi ça te sert donc ?
- ton code n'est pas du tout aéré.
- tu as irrégulièrement de l'implémentation dans tes .hpp.
- Comment je peux travailler avec 2 fichiers sur le même écran avec vim sur ton code si les lignes font plus de 100 caractères de long ?
- Ton design parfois est bizarre, tu met des classes qui ont plus une sémantique "game" dans ta partie "graphic" (par exemple graphic/2d/map.h)
- ton code est assez mal documenté (partiellement dirons nous).
Dès que je vois cette documentation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
* \file action.h
* \class Action
* \brief Link SFML events to odfaeg actions.
* \author Duroisin.L
* \version 1.0
* \date 1/02/2014
* Link one or more SFML Events to ACTIONS, and determine when the action is triggered.
* The sf::Events are stored into the leafs of a BSP tree structure.
* It means that combined actions contains two children :
-The first action child is linked to the first SFML event.
-The second action child is linked to the second SFML event.
-The combined actions contains also a pointer to a function who determine when the combined action is triggered.
by exemple the xor function return true if one of the two action's children is triggered.
*/

Je trouve que c'est beaucoup trop. Doxygen est capable de trouver le fichier, le nom de la classe tout seul. J'aurais vu ça comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
/**
 * \brief Link SFML events to odfaeg actions.
 * Link one or more SFML Events to ACTIONS, and determine when the action is triggered.
 * The sf::Events are stored into the leafs of a BSP tree structure.
 * It means that combined actions contains two children :
 * -The first action child is linked to the first SFML event.
 * -The second action child is linked to the second SFML event.
 * -The combined actions contains also a pointer to a function who determine when the combined action is triggered.
 * by exemple the xor function return true if one of the two action's children is triggered.
 * \author Duroisin.L
 * \version 1.0
 * \date 1/02/2014
 */

L'auteur, la date et la version ça ne sert à rien à ce niveau, utilise git pour ça ! (Note au passage que je ne comprends pas comment tu peux stocker des info non-spatiales dans un BSP tree. Et de toute manière les détails d'implémentation n'ont rien à faire dans la doc de tes headers).

Bref, je serais toi pour l'instant je clarifierais tout mon moteur (réécriture de la doc + remise à zéro du repo avec des commits git atomiques et soignés), aération du code, implémentation non template dans les cpp quand pas inline, un sous namespace par sous-dossier (au passage peut-être déplacer des classes), la sfml ne la copie-colle pas dans ton moteur, explicite là en tant que dépendance, etc.
Ah et les "#include ../gnagnagna" ça n'est pas très propre je trouve.
Enfin si j'ai un conseil à te donner c'est pour l'instant de laisser un peu de coté les features pour te concentrer sur la gestion/écriture du code. Ça prends plus de temps mais ça permet de travailler bien plus sereinement je trouve (finalement t'y gagne) !


En tout cas je te félicite quand même pour ton travail parce qu'on voit que t'as fourni du boulot (même si je ne peux pas juger en profondeur ce que tu as fait). Ce que je te dis c'est juste pour que tu puisses travailler avec une démarche un peu plus saine, là tu rush c'est pas bon, prends le temps de très bien faire, vu que t'as la passion autant la servir au mieux

Bonne continuation à toi !

[Invité]

Ok, oui en effet je dois nettoyer le code, j'attendais juste d'avoir un code en construction qui fonctionne pour le faire pour ne pas devoir à chaque fois regénérer la doc, recréer et effacer des fichiers .h, .impl et .cpp (j'ai donc tout mis dans les .h)

Mais maintenant que le plus gros du moteur fonctionne. (tout du moins, chez moi)

Je vais voir comment je peux mieux soigner le code.

Le répertoire git-hub ne me sert à rien pour le moment à part pour la sauvegarde, mais tu as raison, je crois que je vais le reset, maintenant que tu me le dit, il y a pas mal de crasse qui se sont ajoutées.

Je me suis juste contenté de faire des git-push, des git-commits et des git-add.

T'entends quoi par commit atomiques ? Un seul commit par fichier ? Il y a moyen de faire ça ?

Je ne savais pas, merci, je vais retravailler ça! (A vrai dire je crois que c'est la seule chose qui me manque encore pour être un bon codeur, après ça à vrai dire je n'aurai plus que l'IA a faire et corriger les derniers bugs de la version BETA mais tout ça c'est pour la démo, pas vraiment pour le moteur.)
Au niveau de la 2D j'ai presque fini.

La classe map je vais la renommer car c'est pas vraiment une map, c'est pas une classe du jeux c'est juste un gestionnaire d'entités. (Dont je vais me servir d'ailleurs pour transférer les entités en réseau ou bien les sauvegarder dans un fichier)

A vrai dire y'a aucun classe du jeux dans le framework.

Et oui j'ai copié du code de SFML que j'ai modifier pour afficher de la 3D, intégrer les VBO, etc....

Ca aussi il faudra que je précise que j'utilise SFML comme une dépendance et que je n'ai pas fais que du copier collé de SFML.

Pour le BSP tree ça il faudra demander à l'auteur de la bibliothèque thor sur laquelle je me suis inspiré.

[yetimothee]

T'entends quoi par commit atomiques ? Un seul commit par fichier ? Il y a moyen de faire ça ?

Pas forcément un seul fichier. Par atomique j'entends pour chaque chose indépendante que tu fais. Le but c'est que tu puisses vraiment avoir l'historique de ton développement, que ce soit clair, logique. C'est à dire que le plus de modifications indépendantes les unes des autres doivent être considérés à part. En gros quand tu vas être amené à relire ton log git pour reprendre une feature codée auparavant, ça va être clair et tu vas voir la démarche que tu as eu. Dans un message de commit il ne faut pas hésiter à être précis sur le pourquoi des choses (implémentation, etc). Je ne peux pas t'en dire plus mais je pense qu'en tapant "git good usage" dans google tu vas trouver ton bonheur !
Pour expliquer atomique, je pense qu'il faut partir sur la chimie, une molécule c'est un ensemble d'atomes mis en relations. Donc ton programme c'est une très grosse molécule (ou même un ensemble de molécules), et pour bâtir cette molécule il a déjà fallu que tu bâtisse les atomes (et pour les atomes les quartz et tout ça mais bref !), je pense que tu vois le topo. Pour ton moteur là une centaine de commits n'auraient pas été de trop !

Là le truc c'est que tu vas te casser les dents à tout refaire (les commits), donc ce que je te propose c'est de partir d'un seul commit qui reprenne l'ensemble de ton travail actuel (ou un commit par sous partie de ton moteur, ou bien un par classe mais bref, libre à toi), et qu'à l'avenir tu détail davantage. Il ne faut pas que ça soit une torture

A vrai dire je crois que c'est la seule chose qui me manque encore pour être un bon codeur, après ça à vrai dire je n'aurai plus que l'IA a faire et corriger les derniers bugs de la version BETA mais tout ça c'est pour la démo, pas vraiment pour le moteur.

Alala, si c'était aussi simple ! Mais oui ça fait parti du boulot, faire un code propre ça aide à se sentir bien dans son développement, à mieux anticiper les erreurs et surtout pouvoir se dire "je peux facilement faire marche arrière". Un livre qui m'a beaucoup aidé c'est "Pragmatic Programmer", qui détail un peu le quotidien de développeurs aguerris, des techniques qui permettent d'arriver à ses fins, etc. Je serais toi j'aurais ce genre de bouquins en livre de chevet, ça aide tellement !
Pour l'IA c'est un domaine à part entière. Là aussi déjà il faut commencer par se documenter à fond avant de se lancer, imho

Voilà, en tout cas je te souhaite bon courage pour la suite !

[Invité]

Ok merci, je vais essayé de me renseigner sur ça, c'est vrai qu'un historique ça pourrait être pas mal.

Surtout si un jour je décide de reprendre le code que j'avais écris autre fois (je le fais déjà avec la sauvegarde) car le nouveau code ne fonctionne pas par exemple mais bon un log me permettrait de comprendre le code précédent.

Ouais c'est vrai que pour tester divers implémentation ça pourrait être pas mal, il faudrait que je me renseigne un peu sur git, car, là, j'avoue que à part les commits que je fait sur tous le projets, les git-push et les git-add, je ne connais pas grand chose.

Bref, je stoppe l'ajout de fonctionnalités pour l'instant, je vais clarifier un peu tout ça et il y a pas mal de boulot. ^

[Kannagi]

Je pense comme yetimothee , faire un code propre et modulable augmente la productivité dans le long terme , certes coder comme un 'bourrin' on peut avoir des résultats rapide (pratique pour testé ces algo ) , mais sur le long terme t'aura des fonctionnalité qui te bloqueront parce que peu maintenable et tu le trainera comme un boulet (si c'est tout le code alors ça peut être très galère).

Pour ma part j'ai pas lu beaucoup de livre sur les bonnes pratiques mais je me base sur ces règles : une bonne fonctionnalité est une fonctionnalité qui est réutilisable sur un autre programme , facile a utilisé et facilement maintenable si cela répond a ces trois critères en général je la garde.
En général faire des fonctionnalité trop général casse cette logique du coup je préfère réduire leur portée de fonctionnalité quitte a en faire plusieurs qui se 'ressemble'.

[Invité]

Pareil je vise à faire ce genre de fonctionnalité aussi, mais là je dois encore nettoyer le code pour la maintenabilité.

Je veux faire un maximum de classes qui sont réutilisable partout dans le code et aussi dans un autre programme, par exemple :

-Je veux que les classes d'affichages et de gestion de collisions 3D soient réutilisable pour la 2D.

-Je veux avoir un système de commande avec des fonctions qui sont réutilisable partout dans le programme et pas de bêtes fonctions que je construis avec std::bind et des placeholders, et dont je ne peux pas réutiliser le pointeur de fonction par la suite ni la stocker pour la connecter à une autre fonction ou bien encore à un événement d'une autre bibliothèque ou d'un autre programme.

-Je veux aussi avoir une librairie qui soit utilisable sur plusieurs plateformes, peu importe la version d'opengl, sans devoir changer le code.
-Et je veux également pouvoir transférer des données sur le réseau ou bien les sauvegarder sans devoir changer trop de code également.

-Et de même pour toutes les autres fonctionnalité de la librairie.

Je vais voir ce que je peux faire côté maintenabilité pour améliorer ça, je sais que je dois déjà :

-Remplacer les #include "../../../blablablah" par des #include <blablablah>
-Faire des fichiers qui regroupent plusieurs fichiers d'en tête comme le fait SFML.
-Faire des sous namespace pour les différents modules.
-Mettre tout ce que j'avais laissé bêtement dans les .h juste pour tester des alforithmes de manière rapide dans des fichiers .cpp, ou bien .impl pour les template.
-Mettre au point le "linkage dynamique" afin d'éviter de devoir "linker" trop de dépendances.
-Finir la doc.

Une fois que j'aurai fais tout ça je pense que je pourrai repartir sur des nouvelles fonctionnalités que je documenterai au fur et à mesure. (Je pense que des logiciels tel que blender devraient m'aider à mieux visualisé mes algorithmes de détection de collisions, il me faudrait aussi un logiciel pour déboguer avec les shaders.

Mais ici je vais finir de rendre ça plus maintenable afin de sortir la 1ère véritable release de la bibliothèque et débuguer ce qu'il y a encore à débuguer à l'aide de la démo.

PS : et bien sûr rendre son utilisation la plus simple possible en conservant la rapidité d'exécution.

J'ai trouvé que beaucoup de librairies actuelles sont encore trop difficile d'utilisation, et trop compliquée à comprendre.

Mon but n'est donc pas de faire une usine à gaz.

[Invité]

Re,

j'ai fait quelques améliorations au niveau du code source (celui du delegate) en utilisant std;;function et aussi au niveau du système de sérialization grâce à certains membres de ce site.

Je vais donc attaquer maintenant la documentation et la sépration du code source dans les fichiers et je reseterai le git-hub une fois tout ça de fait.

[Invité]

Je suis entrain de commenter le code afin de générer la documentation, par contre, je ne sais pas du tout comment faire pour générer la documentation à partir des commentaires avec doxyblock. (Et je n'ai rien trouvé là dessus)

Même chose en ce qui concerne les commits avec github.

[Cirrus Minor]

Même chose en ce qui concerne les commits avec github.

Github, c'est Git.
Git est un outil en ligne de commande, tu peux trouver plein de doc à son propos, mais en gros:
- tu fais des "commit" pour chaque fonctionnalité, avec un commentaire associé,
- un commit est local, de temps en temps tu dois les envoyer au serveur avec un "push".

J'ai GitHub sous Windows, et il est fourni avec une IHM qui permet de facilement faire des commits, ou de synchroniser le client et le serveur, tu as peut-être aussi une IHM GitHub sur ton système, et si ce n'est pas le cas tu peux trouver d'autres frontends pour Git.

[Invité]

Ha non je n'ai pas de ihm, je suis sous ubuntu et j'utilise git en mode console.

Bref, ok, Je vais essayer de trouver une ihm.

[yahiko]

En local, j'utilise Git GUI. Je suis sur Windows, mais je pense que cette IHM doit être disponible sous d'autres OS.

EDIT : J'ai trouvé une liste des clients Git : http://git-scm.com/download/gui/linux

[Invité]

Ok, je note ici alors les dernières choses à faire avant la sortie de la bêta :

-Remplacer le singleton par un contexte pour la gestion des ressources.
-Utiliser une gui pour le dépôt git.
-Générer de la documentation avec doxygen.
-Utiliser les pointeurs intelligents de la STL partout.
-Mieux séparer et aérer le code source.
-Faire le site web de la bibliothèque.