Module Irrlicht en développement

En fait je vais pas vraiment avoir le temps de m en occuper dans les jours qui viennent mais d'ici 1 petite semaine je me met dedans.

Désolé pour le retard, j'ai été pas mal occupé ces derniers jours

J'ai commencé a regarder tout ca. Voila ce que j'ai fait pour l'instant :

• Création d'un projet visual et reorganisation des fichiers pour pouvoir coller direct le module dans le repertoire de SPARK
  
• Passage a la licence zlib
  
• Il y avait des cast qui manquaient par ci par la
  
• Les classes peuvent maintenant s'exporter et s'importer (prefixes __declspec(dllexport) / __declspec(dllimport))
  
• la méthode render héritée de SPK::System ne faisait rien, elle redirige maintenant vers le render hérité d'Irrlicht
  
• Il y avait des utilisation de dimension2du qui n'est pas défini. Plutot que de le définir, je les ai remplacé par des dimension2d<irr::u32>
  

Donc maintenant ca compile bien sous visual en statique et en dynamique sans warning

Maintenant je vais vraiment me plonger dedans :

• Permettre l'emission des particules dans le repere monde
  
• Tester un peu les fonctionnalités implémentée
  
• Regarder pour le rendu par point qui clignote
  
• Voir s'il n'y a pas de probleme entre le comptage de reference de SPARK et celui d'Irrlicht
  
• J'aimerais bien aussi faire un bench avec le systeme de particule d'irrlicht et SPARK (meme rendu en comparant les perf)
  
• Une démos mettant en avant tous les trucs qu'on peut faire avec SPARK et pas avec Irrlicht aussi peut etre
  

Voila, je reposte mes avancées bientot.

Pour l'export des classes, le declspec n'est pas forcément obligatoire, il me semble que dans la démo de feux j'utilise des classes exportées sans declspec. Mais pour la lecture c'est mieux les declspec donc bon.

Les dimension2du existent dans la version 1.6 SVN d'irrlicht.

Sinon, pourra tu me passer tout le renderer quand tu aura terminé, histoire de voir à quoi ca ressemble et d'avoir les même sources pour l'améliorer (pendant les vacances de la Toussaint sans doute)?

@+

PS: une petite idée comme ca: puisque le projet est open-source, pourquoi ne pas monter un SVN ? Je pense que ca aidera beaucoup si la librairie se fait connaitre.

PS2: Je te conseille de présenter SPARK sur le forum d'Irrlicht en présentant aussi le renderer Irrlicht (sinon ca n'interessera personne sur le forum), ou sinon je le fais (si ca t'arrange).

Darktib wrote:

Pour l'export des classes, le declspec n'est pas forcément obligatoire, il me semble que dans la démo de feux j'utilise des classes exportées sans declspec. Mais pour la lecture c'est mieux les declspec donc bon.

En fait si le __declspec(export) est obligatoire (enfin soit ca, soit un fichier de definition .def) si tu veux pouvoir acceder aux fonctions / data en dehors de la DLL. Tu dis ca par rapport a Irrlicht j'imagine. Il n'utilise quasiment pas de __declspec(export) en fait car beaucoup de chose ssont entierement definies dans les headers. Pour ce qui ne l'est pas, Irrlicht utilise en fait des bridge (separation de l'interface et de la implementation dans 2 classes distinctes), le tout sans doute couplé a une fabrique pour créer les objets. Du coup l'utilisateur n'a jamais besoin d'utiliser les classes d'implémentation puisqu'il passe par les classes d'interface qui ne sont en fait qu'un set de fonctions virtuelles pures qui sont definies dans les headers donc accessible en dehors de la DLL.

Concernant le __declspec(import), lui est en effet optionnel mais le mettre est mieux, ca permet au compilo d'optimiser le code car on lui assure que cette fonction est définie dans une DLL.

Mais dans le renderer Irrlicht pour SPARK, il faut les declspec a certaines place pour pouvoir créer une bibliotheque dynamique.

Quote :

Les dimension2du existent dans la version 1.6 SVN d'irrlicht.

Ok. Je pense qu'il faut mieux se baser sur la derniere release stable plutot que sur la version sur SVN, du coup il faut mieux oublier dimension2du pour l'instant. On le changera quand la 1.6 sortira

Quote :

Sinon, pourra tu me passer tout le renderer quand tu aura terminé, histoire de voir à quoi ca ressemble et d'avoir les même sources pour l'améliorer (pendant les vacances de la Toussaint sans doute)?

Oui evidemment

Quote :

PS: une petite idée comme ca: puisque le projet est open-source, pourquoi ne pas monter un SVN ? Je pense que ca aidera beaucoup si la librairie se fait connaitre.

Un SVN peut etre utile en effet mais il faut pour cela qu'on soit plusieurs a travailler sur la lib en meme temps. Ce qui n'est pas vraiment le cas pour l'instant. Mais plus tard pourquoi pas.

Quote :

PS2: Je te conseille de présenter SPARK sur le forum d'Irrlicht en présentant aussi le renderer Irrlicht (sinon ca n'interessera personne sur le forum), ou sinon je le fais (si ca t'arrange).

Oui on fera tout ca en temps et en heure

Avant faut finaliser le truc et s'assurer qu'il n'y a pas trop de bugs avec une petite serie de tests unitaires

Apres reflexion, je me suis dit qu'il fallait peut etre changer le design des renderers Irrlicht. En fait il serait bien de pouvoir extraire une interface commune par type de renderer qui soit independant de la plateforme. Ca permettrait plusiseurs trucs :

• Factoriser des fonctionnalites :
  
  
  
  • L'implementation de nouvelles plateforme sera faciliter
    
  • La maintenabilite du code egalement
    
  
  
• Interface de classe commune
  
  
  
  • Meilleure abstraction de la plateforme
    
  • Faciliter la mise en place d'un editeur multiplateforme
    
  
  
• Unifier le design de la bibliotheque
  
  
  
  • Apprentissage facilite
    
  • Meilleur lisibilite du code
    
  
  

Ton design base sur les bridges en ayant une classe d'interface et 3 classes d'implementation (a la Irrlicht on va dire) n'est pas mauvais, loin de la, mais il s'inscrit moins dans la philosophie de SPARK qui sertait plutot une classe mere et 3 classes derivees.

Serais tu ok pour que je refactorise tout ca, tout en conservant ton implementation mais en modifiant en fait uniquement l'interface pour la rendre identique aux autres modules de rendu. Comme ca, et avec le renderer Direct3D qui va arrive, je pourrai reussir a extraire une interface commune par type de renderer. Ainsi je pourrai rajouter directement le module Irrlicht et le module Direct3D directement en temps que modules officiels et les sortir en meme temps que la version 1.04 de SPARK. Je pourrais faire tout ca assez rapidement.

Comme ca, on aura un package complet bien coherent et robuste.

Qu'en penses tu ?

En gros : meme interface que pour le GLRenderer ? Pourquoi pas, mais je pense qu'une classe englobant le tout ne serait pas mal non plus.

Il y aurais alors tous les modules facon GLRenderer, puis une classe utilisant le tout (mais dont l'utilisation ne serait pas obligatoire) qui ferais l'équivalent de la classe IrrRenderer ? Comme ca les deux méthodes seront possible ?

Si c'est pour la cohérence de la librairie et sa robustesse, je suis d'accord. Mais je pense qui faudrait un peu plus expliciter la nouvelle interface.

En gros c est juste pour unifier l interface. Oui ce serait plus ou moins calque sur les renderers OpenGL

Je rajoute juste des classes interface :
LineRendererInterface
QuadRendererInterface
PointRendererInterface
...

Ces classes definissent en fait juste des contrats pour les renderers en imposant une interface (par exemple setLength, getLength pour les renderers de lignes...), ce ne sont pas des renderers, juste un set d accesseurs/mutateurs/membres plus eventuellemt quelques fonctions utilitaires. Les renderers qui heritent d'une interface ont pour contrat de la respecter. Ca unifie la bibliotheque et me permettra d'utiliser le polymorphisme dans l editeur pour faciliter sa conception (parceque coder un editeur pour gerer tous les rendereurs et qui soit evolutif n est pas si evident que ca).

En fait comme je compte rajouter les modules Irrlicht et Direct3D directement dans la lib, j aimerai bien que tout soit unifie. En plus de tous les avantages que j ai enonce dans mon message precedent.

Si tu veux, je t upload le nouveau GLLineRenderer ce soir pour que tu vois de quoi ca a l air. En fait j ai juste deporte l interface qu on peux considerer commune a un type donnee de renderer dans une autre classe, c est tout.

Pour l instant, c est juste ca. Mais apres on peut reflechir a une reelle abstraction de la lib de rendu en passant par une fabrique abstraite pour les renderers et les systemes par exemple, mais bon ca c est pas pour tout de suite.

OK, si c'est bien tout uniformiser comme ca, je suis d'accord. Il faudra juste rajouter une fabrique.

Pour l'éditeur, avec quel bibliothèque de GUI compte tu le faire? Qt, WxWidgets, GTK, ... ?

Perso, je te conseille Qt + soit API en direct, soit avec Irrlicht. Si tu veux des codes sources pour intégrer Irrlicht à Qt, dis-le moi.

Je me suis pas encore vraiment arrété sur le choix mais je pense que ce sera Qt en effet.

Pour le rendu des particules dans l'éditeur, bah ce se fera avec l'API qui va bien en fonction des renderers utilisés.

Salut,

juste un petit mot pour dire qu'apres avoir quasiment terminé la base de la version 1.04.00 de SPARK, je me suis lancé dans l'intégration de ton module de rendu pour Irrlicht.

J'ai pas mal epluché le code source d'Irrlicht et il y a des trucs cools et des trucs moins cools :

• J'ai pu trouvé un material qui permettait de configurer le mode de blending précisément, ce qui enleve tous les problèmes de blending qu'il pouvait y avoir. C'est le material EMT_ONETEXTURE_BLEND. Tant mieux, j'avais pas vraiment envie de coder un materialRenderer spécifique pour SPARK.
  
• J'ai intégré le rendu des POINT_SPRITES mais malheureusement le support des POINTS et des POINT SPRITES n'est pas terrible dans Irrlicht. Du coup impossible pour l'instant de simuler des quads avec des points correctement. Il n'y a pas grand chose a changer dans Irrlicht pour que ca fonctionne, je mettrai un post a ce sujet plus tard dans leur forum.
  
• Je n'en suis pas encore sur mais j'ai l'impression qu'il est impossible de stocker des buffers coté hardware en utilisant le drawVertexPrimitiveList. Ce qui est dommage parceque ca oblige a renvoyer les index a chaque fois au GPU qlors qu'ils sont statiques. Il faudra que je creuse plus tout ca.
  

Sinon coté modif dans le module pour Irrlicht, comme je te l'ai dis j'ai reorganisé les renderers pour que ca fit bien avec la nouvelle version de SPARK. J'ai aussi completement encapsulé le material dans le renderer. Sinon je pense changer un peu le IRRBuffer pour le rendre plus generique (par exemple, dans l etat actuel des choses, si on veut ajouter un renderer pour rendre les particules avec des meshs, ca oblige a modifier le buffer, il faut plus de généricité). Et puis un peu de debugging aussi. Sinon j'ai bien aimé le fait que l'update et le draw puisse etre automatisé avec IrrSystem. Et puis aussi le fait qu on puisse choisir de ne plus updater un systeme hors du frustum.

Reste quelques trucs a faire. Je prend pas mal mon temps parceque je veux faire une bonne version. J'aimerais aussi faire une démo qui présente plusieurs systèmes montrant un peu les possibilités de SPARK avec Irrlicht.

Bref, je posterai la version 1.04.00 avec le module d'Irrlicht sur le forum avant de la mettre sur le site, histoire que tu vois ce que ca donne et que tu me dises ce que tu en penses. Idealement j'aimerai aussi mettre le module pour DirectX9 dans cette version mais on verra ca.

Ok, très bien. Par contre, je pense qu'on devrait toujours laisser à l'utilisateur la possibilité de changer le matérial (mais je pense que c'est le cas). Pour les VBOs il me semble qu'il faut passer par les mesh buffers, en théorie il va y avoir de profondes modifications sur ce sujet (notamment l'ajout de buffers ne contenant que des vertex ou des index, permettant de faire l'équivalent d'un drawVertexPrimitiveList).

As tu une estimation de la date à laquelle tu pense avoir fini ?

Salut,

bah en fait concernant le material, il n'y a plus acces directement parceque j'ai besoin de locker des trucs dedans et il ne faut pas que l'utilisateur mette le bordel la dedans. Donc la il est complement encapsulé mais par contre il y a des accesseurs/mutateurs pour accéder/setté les données interessantes dans le material pour un système de particules. Comme ca, on a meilleur controle sur le material et on c'est plus facile pour l'utilisateur (par exemple j'ai fait une enum pour setter le blending)

Oui les VBO, il faut passer par des mesh buffers effectivement (enfin c est ce que j ai vu en regardant vite fait les source d irrlicht), donc limité le rendu aux triangles. En fait la j'ai terminé quasiment l'adaptation, il me reste le buffers a changer un peu pour le rendre plus générique. J'ai vu qu'il y avait une classe DynamicMeshBuffer qui me semble pas mal pour utiliser les indices en 32bits (plutot que d'avoir 2 tableaux), je vais regarder de ce coté la.

Apres me reste de la doc a faire et la démo. Pour la date je dirais a priori cette semaine. Enfin tout depend si j'ai le temps de finir tout ca.

En tout cas merci beaucoup pour le module de rendu Irrlicht et aussi pour l'idée de le faire, ca m'a permis d'améliorer pas mal la lib et de la rendre plus générique.

Pour les metarials, je pense que le mieux c'est aussi de donner le libre accès (que locke tu dans le material?)
Les VBOs sont utilisables avec les lignes et les points, mais il faut truquer un peu.
Les DynamixMeshBuffers sont en cours d'implémentation si je me souviens bien -mais je te conseille d'essayer, ca fait un bout de temps que je ne me suis pas lis à jour sur cette info^^

Et ce fut aussi un plaisir que d'implémenter le renderer - d'ailleurs merci pour un tel moteur de particules!

Bon courage!

Bah en fait pour les materials, il y a le type du material (ONE_TEXTUREBLEND) qui est fixe et en fait il faut passer par une fonction pour setter le blending correctement (car le material ONE_TEXTUREBLEND "encode" les info de blendiong dans son parametre additionnel). Ensuite le culling backface est locke en desactive (ca n a pas de sens de faire du culling backface sur des quads oriente, ca rajoute de la lourdeur et puis maintenant que les quads peuvent etre oriente un peu comme on veut, il peuvent tres bien montrer leur face arriere), le gouraud shading est aussi desactive (En utilisant du flat ca permet de ne renseigner au rendu qu une couleur par primitive plutot qu une par vertex)...

Et puis en gros, ca permet de presenter une interface plus facile a utiliser avec juste un acces aux trucs utiles pour l utilisateur. Apres le material est toujours recuperable en consultation (pour le copier par exemple ou n'importe quoi) Enfin tu y verra peut etre plus clair quand je posterai le code.

Pour les VBO on va pas les utiliser pour le moment. Ca pourra etre fait dans une mise a jour eventuelle.

Sinon sais tu s il y a moyen de faire du geometry instancing hardware avec Irrlicht ? Ca peut etre tres utile pour rendre des particules avec des mesh.

Geometry instancing hard ? Que veux tu exactement dire par là?

Sinon ok pour le matériaux, meme si je pense que laisser la possibilité à l'utilisateur de tout controler en plus serait pas mal. Par exemple, pour le gouraud shading, je connais un jeu (pas en C++) dans lequel les devs ont mis un système de particules avec gouraud shading (pas pour tous les systèmes, juste pour un effet de fumée), et ca peut rendre très bien. Si j'ai bien compris ce que tu as dit, il est possible de récupérer une référence sur le materiaux ?

Bah en fait si on veut faire du gouraud shading, il faut utiliser au moins 2 couleurs par particules pour faire le shading (sinon ca sert a rien) et donc implémenter un renderer custom, et la on a acces au material du coup. Oui c'est possible de recuperer une ref constante sur le materiau.

Le geometry instancing c'est une technique implémentée sur OpenGL et Direct3D qui permet d'optimiser le rendu d'un meme mesh plusieurs fois a la suite en utilisant la puissance de calcul parallele des GPU. On quand meme la possibilité de setter certaines données par mesh rendu (transformation, couleur...). Bref c'est idéal pour rendre des particules qui sont rendus avec des meshs.

Pour le geometry instancing je ne sait pas, va falloir demander sur le fofo d'Irrlicht. Par contre ca m'interesse aussi, pour d'autres projets.

Salut,

j'ai fait un petit bench pour comparer les performances du systeme de particules interne a Irrlicht et de SPARK en construisant le meme systeme simple, 1 fois avec le systeme de particules d'Irrlicht et 1 fois avec SPARK.

J'ai été assez surpris de voir que SPARK est plus de 4 fois plus rapide qu'Irrlicht (et sans utiliser les points sprites !). Chez moi j'ai dans les 120fps pour le bench avec les particules d'Irrlicht et 500 pour SPARK. De plus SPARK gere bien mieux les pics de delta time : En mettant en pause Irrlicht avec alt, et en reprenant l'execution, les particules avec Irrlicht sont dans les choux alors que celle de SPARK reprennent bien.

Pour la consommation memoire c'est a peu pres equivalent (16416 pour Irrlicht contre 16476 pour SPARK)

C'est pas un test exact non plus (puisque sur un systeme en particulier et non une généralité) mais ca donne une bonne idée du gain de performance de SPARK. Personnelement je ne m'attendais pas a ca. Je pensais que SPARK était interessant surtout pour sa flexibilité et ses fonctionnalités accrus par rapport au système d'Irrlicht mais il a l'air egalement beaucoup plus rapide.

Au passage les 2 systèmes ne sont pas exactement identiques, mais j'ai bidouillé un peu les valeurs (notamment la gravité qui a l'air gérée différemment avec Irrlicht) pour arriver un 2 systèmes a peu pres semblables.

Le système de test a environ 7000 particules (on peut pas monter bcp plus haut avec les particules d'Irrlicht) qui fade et sont affectées par une gravité.
Elles sont émises a partir d'une sphere et on une taille initiale et une couleur initiale variable.

Voila le code pour le système de particules d'Irrlicht :

Code:

scene::IParticleSystemSceneNode* ps = smgr->addParticleSystemSceneNode(false);

scene::IParticleEmitter* em = ps->createSphereEmitter(
   core::vector3df(0.0f,-20.0f,-50.0f),
   1.0f,
            core::vector3df(0.0f,0.1f,0.0f),
            7500,7500,
            video::SColor(0,255,0,0),
            video::SColor(0,255,255,0),
            800,1000,25,
            core::dimension2df(0.2f,0.2f),
            core::dimension2df(0.8f,0.8f));

ps->setEmitter(em);
em->drop();

scene::IParticleAffector* paf = ps->createFadeOutParticleAffector();
ps->addAffector(paf);
paf->drop();

scene::IParticleAffector* paf2 = ps->createGravityAffector(core::vector3df(0.0f,-1.2f,0.0f),10000);
ps->addAffector(paf2);
paf2->drop();

ps->setMaterialFlag(video::EMF_LIGHTING, false);
ps->setMaterialFlag(video::EMF_ZWRITE_ENABLE, false);
ps->setMaterialTexture(0, driver->getTexture("res\\point.bmp"));
ps->setMaterialType(video::EMT_TRANSPARENT_VERTEX_ALPHA);

voila le code pour le système avec SPARK :

Code:

randomSeed = device->getTimer()->getRealTime();
Vector3D gravity(0.0f,-130.0f,0.0f);

IRRQuadRenderer* particleRenderer = IRRQuadRenderer::create(device);
particleRenderer->setTexture(driver->getTexture("res\\point.bmp"));
particleRenderer->setTexturingMode(TEXTURE_2D);
particleRenderer->setBlending(IRR_BLENDING_ADD);
particleRenderer->enableRenderingHint(DEPTH_WRITE,false);

Model* particleModel = Model::create(
   FLAG_RED | FLAG_GREEN | FLAG_BLUE | FLAG_ALPHA | FLAG_SIZE,
   FLAG_ALPHA,
   FLAG_GREEN | FLAG_SIZE);
particleModel->setParam(PARAM_RED,1.0f);
particleModel->setParam(PARAM_GREEN,0.0f,1.0f);
particleModel->setParam(PARAM_BLUE,0.0f);
particleModel->setParam(PARAM_ALPHA,1.0f,0.0f);
particleModel->setParam(PARAM_SIZE,0.2f,0.8f);
particleModel->setLifeTime(0.8f,1.0f);

Sphere* sphere = Sphere::create(Vector3D(0.0f,-20.0f,-50.0f),1.0f);
SphericEmitter* particleEmitter = SphericEmitter::create(Vector3D(0.0f,1.0f,0.0f),0.0f,50.0f * PI / 180.0f);
particleEmitter->setZone(sphere);
particleEmitter->setFlow(7500);
particleEmitter->setForce(100.0f,100.0f);

Group* particleGroup = Group::create(particleModel,7500);
particleGroup->addEmitter(particleEmitter);
particleGroup->setRenderer(particleRenderer);
particleGroup->setGravity(gravity);

IRRSystem* particleSystem = IRRSystem::create(smgr->getRootSceneNode(),smgr);
particleSystem->addGroup(particleGroup);

Si ceux qui passe sur ce thread peuvent télécharger le bench et me dire si les résultats obtenus sont comparables aux miens :
bench SPARK / Irrlicht

Quote :

Si ceux qui passe sur ce thread peuvent télécharger le bench et me dire si les résultats obtenus sont comparables aux miens

sur un modeste portable avec une ATI9700 pro j'obtiens moins de 5 fps avec le moteur natif d'Irrlicht.
Avec SPARK, j'arrive à rester sans problème au dessus de 165 fps.

oula 5 fps !

J'ai l'impression que le moteur de particules d'Irrlicht gere tres mal l'émission d'un grand nombre de particules par frames. Je pense que c'est lié a la facon dont il gere l'allocation des particules. Il est fait pour des petits systemes.

Sur mon pc par exemple si je laisse alt appuyé trop longtemps et que je reappuye apres pour enlever la pause, le systeme de particules avec Irrlicht ne démarre plus et ca reste bloqué a genre 1fps.

Enfin j'ai fait des tests avec moins de particules et SPARK est toujours plus rapide mais l'ecart est moindre (pour environ 4500, irrlicht est a 500 et spark a 720). Donc apperemment le moteur de particules d'Irrlicht va bien se debrouiller avec un petit nombre de particules emise par systeme mais va mal se scaler.

Irr: 1 fps^^
Spk: 360 fps...

Y vraiment pas photo, ton moteur explose complètement Irrlicht au niveau des particules.
Mais après il faut voir ce que ca donne avec beaucoup plus de systèmes.

En fait c un cas trop stressant pour le moteur d Irrlicht. Parcequ il gere pas tres bien l emission et la suppression de particules (il y a plein de copie). SPARK gere le truc differemment sans faire de copie mais en gerant un pool. Par contre au niveau de la boucle d update pure, celle d Irrlicht est plus light (puisque plus limitee) surtout avec aucun modifieur (puisque dans SPARK il y a la gravite, la friction integre par defaut). Donc en conclusion on peut dire que pour de petits systemes avec tres peu de particules emises, les particules d Irrlicht etant plus simple, il peut etre plus rapide mais par contre des qu on va scaler tout ca, SPARK s en tirera beaucoup mieux (cf le bench). Donc voila il ne faut pas faire une generalite de ce bench. En gros SPARK est plus stable en performance.

Concernant le plus de systemes, SPARK devrait sans sortir bien mieux tout simplement car il est possible de batcher les systemes : Au lieu de multiplier les systemes, on mulitplie les emetteurs au sein d un systeme et toute les particules d un meme type sont gerees et rendues en un appel.

PS : Darktib, normalement je poste le code de la pre version 1.04.00 avec le module Irrlicht integree tres bientot sur le forum pour que tu vois ce que ca donne.

OK, j'ai hate de voir ca!

Voila la nouvelle version de SPARK avec les renderers Irrlicht. Tu peux regarder et me dire ce que tu en penses.

Au niveau Irrlicht :
J'ai changé le buffer : ca utilise maintenant un DynamicMeshBuffer pour pouvoir gérer les indices 32 bits de facon plus propre. J'ai aussi reussi a utiliser les VBO avec les quads mais c'est un peu de la bidouille. En tout cas j'ai fait quelques tests et ca peut donner un petit gain pour des gros systemes. Maintenant leur systeme de VBO est assez rigide, c'est un peu dommage, mais comme il est tout jeune ca va allez en s'améliorant je pense.

Sinon j'ai adapté les portages des 2 demos que tu avais fait (basic et fire).

Voila, le module a pas mal changé quand meme surtout au niveau du design pour etre en accord avec la nouvelle version de SPARK.

La il me reste un peu de doc a changer et je pense que je sortirai la version comme ca.

J'attend tes retours.

Je ne suis malheureusement pas sur mon ordi, et ce jusqu'a lundi, donc pas de gros test possible. Je vais quand meme voir si je peux telecharger le zip...

edit: impossible de dezipper, et je n'ai pas le droit d'installer un programme pour decompresser