version 2 sujet à questions en vrac XD

Ok j'ai regardé un peu et c'est plutot cool. Si ca ne te dérange pas je ferais une petite passe dessus pour refactorer quelques trucs, faire quelques optim et faire un retour sur les fonctionnalité non implémentées via le logger. Quand ca tout sera bien uniformiser pour pouvoir l'intégrer.

Par contre un petit truc : évite les commentaires en francais dans le code. La langue de l'informatique c'est l'anglais et puis c'est compréhensible par tout le monde (du moins tout le monde suceptible de lire du code).

En tout cas bravo et merci.

Pour la solution vs2010 pour l'instant je préfere pas parceque si elle est sur le svn ca veut dire la maintenir et maintenir pleins de solutions sur plein d'IDE différents c'est un peu chiant. C'est d'ailleurs pour ca que j'abandonne vs2005.

de toute façon de mon coté non plus j'ai pas tout à fait fini (quelques trucs ne me plaise pas du coté gestion de buffers), donc pas de problème si tu modifies, le svn se chargera des problèmes pour nous ^^

pour les commentaires en français, c'est pur réflexe, je fais jamais gaffe comment j'écris, je changerai ça.

petite erreur (ou pas) dans la classe DataSet, vs râle parce que le destructeur est private.

Oui j'ai vu ca. Une petite erreur que j'ai fait en updatant la doc. Il suffit de repasser le constructeur et le destructeur de DataSet en public.

donc comme vous avez pu le constater (ou pas) je commence à retravailler sur spark.

voilà ce que j'ai fait aujourd'hui (pas encore commité) :

- correction de 2-3 conneries sur les renderers dx9
- première version des renderers dx11 \o/

par contre c'est le gros foutoirs pour dx11, tout étant géré avec des shaders (vertex, geometry et pixel, pour l'instant je laisse le compute), il faut écrire presque un shader pour chaque changement mineur de configuration ...

stardeath wrote:

par contre c'est le gros foutoirs pour dx11, tout étant géré avec des shaders (vertex, geometry et pixel, pour l'instant je laisse le compute), il faut écrire presque un shader pour chaque changement mineur de configuration ...

Pourquoi ne pas utiliser du preprocessing sur les shaders pour éviter que leur nombre grimpe trop ?

Sinon pour les renderers directX 11, c'est peut être un peu tôt dans la mesure ou je compte faire un shader manager pour pouvoir gérer facilement les shaders dans spark, faire un truc un peu unifié quoi.

Essaie de ne pas le pusher dans le tronc pour l'instant. Je vais sans doute faire une branche pour ce genre de feature "r&d" qui seront incluses plus tard.

j'utiliserai le preprocessing, mais pour les tests, mieux vaut les écrire séparément.

pour le shader manager, j'y ai pensé aussi, vu que le glsl et le hlsl prendront à 2-3 exceptions près exactement les mêmes infos.

et ok, je push pas.

en opengl 4, ça marche comment la gestion des différents étages du pipeline?

je m'explique par exemple pour régler le blending, tu remplis une structure avec les différentes infos et tu les envois au pipeline.
tout dans dx11 se règle en envoyant des structures au pipeline.

exemple de code pour bien montrer :

Code:

// la configuration d'un état
ID3D11BlendState* g_pBlendingStateParticle = NULL;
D3D11_BLEND_DESC BlendStateDesc;
ZeroMemory( &BlendStateDesc, sizeof(BlendStateDesc) );
BlendStateDesc.RenderTarget[0].BlendEnable = TRUE;
BlendStateDesc.RenderTarget[0].BlendOp = D3D11_BLEND_OP_ADD;
BlendStateDesc.RenderTarget[0].SrcBlend = D3D11_BLEND_SRC_ALPHA;
BlendStateDesc.RenderTarget[0].DestBlend = D3D11_BLEND_ONE;
BlendStateDesc.RenderTarget[0].BlendOpAlpha = D3D11_BLEND_OP_ADD;
BlendStateDesc.RenderTarget[0].SrcBlendAlpha = D3D11_BLEND_ZERO;
BlendStateDesc.RenderTarget[0].DestBlendAlpha = D3D11_BLEND_ZERO;
BlendStateDesc.RenderTarget[0].RenderTargetWriteMask = 0x0F;
pd3dDevice->CreateBlendState( &BlendStateDesc, &g_pBlendingStateParticle );

// l'envoi au pipeline
pd3dImmediateContext->OMSetBlendState( g_pBlendingStateParticle, D3DXVECTOR4( 0.0f, 0.0f, 0.0f, 0.0f ), 0xFFFFFFFF  );

edit : bon après avoir mieux chercher ça a pas l'air d'avoir changé, ça marche toujours avec des fonctions indépendantes gl*

Je suis en train de regarder SPARK 2 pour une intégration dans l'éditeur d'ici à l'été (à cause des concours...), mais normalement ca ne devrait pas être trop long (dans le code de l'éditeur, il y a à tout casser 3 (petits) fichiers à réviser, le reste se situe au niveau des plugins, qui devront tous être révisés)

Le travail effectué est impressionnant. J'ai vu que tu avais ajouté une classe IOHandler. Cela m'a l'air bien fait, quand j'aurais le temps je pense faire un loader/saver avec un format de fichier que j'ajouterais à l'éditeur. Par contre, comment comptes-tu faire lorsqu'un fichier contient des informations sur les textures (nom des fichiers à charger, etc...) pour que l'utilisateur puisse récupérer ces infos ?

J'ai aussi vu qu'il n'y avait pas d'utilitaires de gestion de doc. Veux-tu que je les commit (ils sont tout prêt) ?

Une autre question: à quoi correspond le "radius" d'un groupe ?

Oui je suis en train de gérer l'IO pour SPARK. Les objets sont décrit à partir d'un descriptor qui peut être importé et exporté. Après il y a un loader et un saver générique. C'est pas encore tout à fait fini, mais pas loin. Après je compte faire une implémentation pour du XML et du binaire.

Sinon je vais aussi sans doute complétement refactorer la facon d'implémenter des renderer pour un moteur. Tout devrait être à base de template. Ce sera très générique, très rapide et permettra de factoriser pas mal le code pour éviter d'avoir à copier/coller toute le traitement du renderer lorsqu'on code une nouvelle implem. Le loading des textures (ou ressource en général) sera lié au moteur implémenté aussi. Les ressource seront sauvegardé avec une clé (typiquement un path). Enfin faut encore que je réfléchisse à ce point.

Bref, rien n'est encore vraiment figé. Ca prend plus de temps que prévu mais çà avance par phase quand j'ai le temps de me mettre dessus. Mais Bon d'ici à cet été çà devrait être bon quand même.

Pour le radius des groupes, il y en a 2 en fait :

• le radius physique qui est le rayon de la particules pour tous les calculs physiques (intersections...)
  
• le radius graphique qui est la taille que la particule prendra à l'écran.
  

Pour les docs je vais réutiliser doxygen et la config de SPARK 1 que tu avais faite (je l'ai peut être un peu tuné je me souviens plus). Enfin je la versionne. Après on peux toujours la modifier.

D'accord.

Pour la doc, la config que j'ai montre toutes les fonctions et classes - même non documentées, ca permet de savoir ce qui existe ainsi que les relations entre elles. Je pense que ca serait utile, je met ca dès que possible (sauf contre-indication^^).

Pour les renderers, tant qu'ils restent Referenceable, il n'y aura pas de changement de code niveau éditeur; sinon je suis curieux de voir la forme que ça va prendre avec les templates.

Le passage de l'éditeur vers SPARK2 a commencé. Pour l'instant ca se passe plutôt bien.
Wait & See ...

edit: pour SPK_START_DESCRIPTION_TEMPLATE il manquait un qualificateur 'inline' ainsi que pour quelques autres fonctions, ca faisait qu'elles n'étaient pas incluses dans la dll => link error.
C'est corrigé dans la dernière révision SVN.

edit2: Au fait, j'ai vu qu'il n'y avait plus les *_All.cpp, qui étaient très pratiques pour compiler rapidement la bibliothèque... et il me semble qu'avec de tels fichiers il était possible de mieux optimiser.

edit3: le code de l'éditeur fonctionne correctement. Par contre j'ai un bug très bizarre, lors de la création d'éléments SPARK, le champ SPKObject::name est complètement corrompu, impossible d'y lire et d'y écrire, même avec le débuggeur... => crash
Ah sinon j'ai vu des nbReference = 3000000 et des bananes, j'ai pas re-regardé le code, mais soit y a un bug, soit la variable n'est pas initialisée (mais j'en doute)...

edit4: A grands maux, grands moyens... j'ai fini par trouver, grâce à Application Verifier. Il y avait un problème de SPK::Ref qui se supprimaient trop tôt. C'est réglé, et tout fonctionne normalement maintenant.

edit5: dernier edit, je pense...
Juste pour signaler que SPK::Point::getClassName() renvoie une chaine vide au lieu de "Point". D'ailleurs, à ce propos, ca serait pas mieux que ce que getClassName() renvoie soit le nom complet (genre "SPK::Ring") ?

Quand tu dis qu'il y avait un bug de SPK::Ref qui était supprimé trop tôt, est ce que c'est un bug dans le moteur ou est ce que tu conservé un pointeur alors qu'il n'y avait plus de SPK::Ref qui le tenait ?

Maintenant tout les SPKObject sont à manipuler uniquement via les Ref qui sont des pointeurs intelligents intrusifs. Dès qu'un SPKObject n'a plus de Ref qui le tient, il est supprimé. Je viens d'ailleurs de refactorer l'interface et maintenant çà vaut aussi pour les System et les Group (avant c'était juste pour les Referenceable).

Pour les _all oui je les ai retiré. C'est vrai que çà accélérait énormément les temps de compile mais les projets étaient moins propres et çà obligeait à tout recompiler pour la moindre modification d'un cpp. Questions optimisations, ca ne change en théorie rien tant que l'optimisation inter-module est activée.

Pour le getClassName, c'est le nom qui sera utilisé pour les export/import d'objets (ca permet d'enregistrer automatiquement les objets sans utiliser de reflection) donc c'est pour çà que le scope est volontairement omis.

Pour le bug des Ref, c'était pas dans le code de SPARK, c'était un pointeur conservé alors qu'il ne fallait pas... Je vais mettre à jour l'éditeur pour les Ref sur les systèmes.
Sinon, je vois mieux à quoi te serviront les className.

Pour ce qui est du passage à SPARK2, pour l'instant tout fonctionne, mais les plugins ne sont pas encore tous portés (seuls les zones le sont), quand j'aurai le temps, je les porterai ; ça sera surement après la création des extensions, qui permettront de réactiver la sauvegarde des effets, threadée cette fois-ci

Une question à propos de l'animation des paramètres. Dans beaucoup de moteurs, quasiment tous les paramètres peuvent être animés (par exemple, animer la direction d'un émetteur), je pense au moteur d'Ogre, à celui de l'UDK, etc...

Je pense que c'est ce que l'on appelle une 'major feature' et que ça devrait être ajouté dans SPARK 2. Pour ça, il y à la solution de l'UDK (chaque variable est en fait une distribution, pouvant être constante, interpolée, aléatoire, etc...), le problème est que tout le code serait à refaire et qu'il n'y aurait presque pas de compatibilité avec SPARK1. Par contre c'est très puissant.
L'autre solution serait -à mon humble avis- de créer une classe 'Animator' qui sera attachée à une propriété d'un objet SPARK (par exemple l'attache au radius d'un groupe) et qui modifierait la propriété en conséquence lors de la mise à jour (les propriétés constantes n'auront évidemment pas besoin d'Animator).

J'ai trouvé cette ressource qui pourrait peut-être être utile: http://today.java.net/pub/a/today/2006/03/16/time-again.html
A noter qu'un portage C++ pour Irrlicht du framework décrit à été réalisé.

Oui en effet c'est une "major feature" de pouvoir controller les paramètres de chaque objet en fonction du temps. J'y ai pas mal pensé et après reflexion j'ai décidé de pas inclure çà dans la première version de spark 2.

Au départ j'avais dans l'idée de faire un truc à base de controlleurs. Le problème est que çà aurait été trop lourd à mettre en place. Donc je me suis dit pas besoin de çà, suffit d'utiliser un langage de script pour le faire...

Mais maintenant que j'ai mis en place tout le système de serialisation/déserialisation d'objet, je pense que les descriptors feraient très bien l'affaire pour permettre de setter n'importe quel paramètre en temps réel. En gros on pourrait attacher un controlleur à n'importe quel SPKObject. Dans ce controlleur, on pourrait ajouter n tracks défini par une chaine de caractère représentant l'id de(s) l'attribut(s) à controller. Comme çà on peut setter/interpoler n'importe quel valeur sérialisable.

Donc en théorie çà peut se faire assez facilement sans toucher au code existant. Il y aura juste de l'optimisation a faire sur les descriptor parce qu'à la base c'est pas fait pour être utiliser en temps réel à chaque frame.

Après un système à base de propriété peut le faire ici.

Bref ca demande de la reflexion et je garde çà pour plus tard pour l'instant.

Pour l'instant je préfère terminer la version 2 sans rajouter des features à implémenter qui ferait encore reculer la release.

Donc la en gros pour la 2.0 il me reste :

• les renderers a refactorer
  
• quelques zones à implémenter
  
• le renderer directX 9 a finaliser
  
• doc + demo
  

Et pour plus tard (2.1 et après) :

• les controlleurs
  
• calculs gpu (vertex et géométrie shader)
  
• effets (pixel shader)
  

Ok, je prend note.

bon le fénéant (moi) est de passage, qu'est ce qu'il y a à faire (dans les renderers dx9) pour pouvoir faire une release officielle du truc?

Hello, la je suis en train de modifier les façons d'implementer les renderers. Une fois que ce sera fait, je porterai le module directX et on le finalisera ensemble si tu veux.

no problem, ça me permettra en attendant de regarder comment faire plus précisément pour les renderers dx11, j'en ai besoin pour un jeu que je suis en train d'écrire.

j'ai rétabli chez moi le fonctionnement des renderers dx9, si ça t'intéresse, je commiterai.

bonne soirée

Cool, ouais tu peux pusher, pas de probleme.

Petite question qui ne nécessite pas un topic je pense...

Actuellement, le logger utilise un std::ostream. C'est bien, mais impossible de dériver efficacement une classe de, par exemple, std::ostringstream, vu que certaines méthodes ne sont pas virtuelles.
Ce que je conseille, c'est de créer une classe Stream (d'ailleurs elle existe déjà), de lui ajouter 4 méthodes virtuelles:

Code:

operator<<(string)
idem avec int
idem avec float
idem avec bool
flush()

Ainsi, il serait très simple, non seulement d'utiliser les classes de la lib standard (au vu des prototypes), et de créer son propre flux sans dépendance avec la stl.

Après, c'est toi qui voit - je suis partant pour faire ce que j'ai proposé, je veux juste ton accord sur l'architecture

Je comprend pas bien.

Le ostream défini les flux standards. Quand tu crées une classe tu peux te implémenter les opérateurs << et >> pour rediriger sur les flux standards (je l'ai fait par exemple pour Vector3D et Color). Pareil tout ces opérateurs sont définis par des fonctions globales pour les types de base dans la STL.

Si tu bypass tout çà, çà fonctionne plus.

Moi si j'ai créé une classe Stream, c'est pour encapsuler le flux standard et rediriger ou non si le logging est activé et la bonne verbosité est settée.
C'est déjà pas la meilleure solution parcequ'on perd l'utilisation des fonctions propres aux flux standards (endl, le formatage...) directement sur le stream. Je devrais changer çà.

Quel est ton problème exactement ?

Je n'ai pas étudié la question en détail pour rediriger les logs dans le cas de ton éditeur mais le logger me parait assez flexible pour que ce soit fait sans trop de difficultés.
Il y a plein de différentes facons de le faire et les classes de la lib standard me paraissent suffisantes. Jette un coup d'oeil a ce thread pour avoir de premières pistes.
Une autre piste serait d'utiliser un stream bidirectionel (le stringstream standard par exemple). le logger envoie les data dans le stream et toi tu les lis sur le stream (avec un getline par exemple)

C'est vrai que ça n'est pas d'une importance capitale, en fait j'ai deux possibilités:
1/ recréer une classe style stringstream completement pour ajouter la chaine au logger lorsque le flux est flushé.
2/ Réimplémenter ostringsteam::flush pour le faire.

Malheureusement, la deuxième possibilité n'est pas possible (les fonctions de stringsteam ne sont pas virtuelles...)... Faire une pseudo interface de flux aurait permit ce genre de chose.
En regardant mieux, je pense que je vais utiliser utiliser la méthode 1, il n'y a probablement pas de besoins suffisant pour changer la manière dont c'est codé actuellement.