renderer directx

En l'utilisateur peut controler lle moment de création des buffers avec des booleen statique :

Code:

Group::enableBuffersManagement(bool)

Par défaut c'est a true, et dans ce cas les eventuels buffer d'un renderer sont créé des qu'il est attaché au groupe. Ceux de l'ancien renderer sont eventuellement effacés.

Et il y a aussi :

Code:

Renderer::enableBuffersCreation(bool)

Par défaut a true aussi, et dans ce cas les buffers sont créés s'ils n'existent pas juste avant le rendu.

En mettant les 2 booleens a false, l'utilisateur controle lui meme la creation des buffers en appelant Renderer::createBuffers (const Group&). Tant que ce n'est pas appelé les buffers ne sont pas crées.

Les buffers sont détruit avec la destruction du groupe.

Concernant le log, oui j'y ai pensé mais en fait je developpe la bibliotheque au fur et a mesure et au début quand c'était encore petit il n'y en avait pas besoin. Maintenant que c'est plus gros, je devrais me pencher dessus. Encore un truc a rajouter a ma liste des choses a faire...

Mais sinon en utilisant le debuggueur, il y a moyen de s'en sortir avec le stack sans doute aussi.

mise à jour reportée, bugs en série (pas du moteur hein, mon adaptation ^^'), memoru leak et autres joyeusetés pas propres

ok, si tu as besoin d'un coup de main, n'hésite pas. Les fuites sont au niveau des buffers de rendu ? C'est possible qu'il y ai des bugs dans le moteur aussi hein.

les pertes de mémoire surtout du à une mauvaise destruction des objets lors de la perte/destruction du device, quasiment résolu.

maintenant il faut que je m'attèle au LineRenderer, vu que le dessin d'une ligne dans opengl ne se fait pas de la même manière que dans dx, surtout au niveau de l'épaisseur des lignes ><

Salut,

ou en es tu du renderer ? En fait comme je l'explique dans le post sur le module Irrlicht, j aimerai changer un peu la facon dont je vais gerer les renderers des differentes plateformes en factorisant par type de renderer generique tout ce qui peut l'etre.

Comme tu t'es base sur les renderers OpenGL, ca ne devrait pas pose de problemes mais en fait j'aimerai sortir la version 1.04 de SPARK avec ces nouvelles interfaces de renderer et les 2 nouveau modules (Irrlicht et Direct3D) directement integre au projet. A moins que la partie Direct3D soit encore loin d'etre terminee, mais il me semble que c'etait quasiment fini nan ?

désolé, surcharge de papier à faire du à ma rentrée, donc où j'en suis :

- j'ai 2 renderers que j'estime pas loin d'être terminé : le point et le quad, le line fonctionne aussi mais ne gère pas l'épaisseur des lignes
je poste le code aussitôt la fin de ce message histoire que tu vois ce que ça donne

- pour les démos, j'en ai 2 :
-- basic démo (dxut et sans dxut)
-- rain démo (dxut seulement)

le code est pas nettoyé, il y a encore des memory leaks, des copiés/collés qui servent à rien etc... bref assez sale

à toi de voir si le nouveau fonctionnement est valide : une classe DX9Info qui contient le device en static comme tu l'avais proposé.

ps: màj de l'archive faite

salut, pas de soucis

J ai regarde un peu ton code, et c est cool. Le comportement a l'air totalement identique a celui des renderers OpenGL.
Il y a juste quelques trucs a optimiser dans les boucles de rendu sans doute (le code apeller pour chaque particule est critique niveau perf) et sinon peut etre renommer les IndexBuffer et VertexBuffer en DX9IndexBuffer et DX9VertexBuffer.

Sinon pour le device statique, c est ok. Personellement j aurai plus mis les infos en statique dans le DX9Renderer car ca evite de creer une nouvelle struct juste pour ca. Et j aurai egalement encapsule les variables statiques avec des mutateurs/accesseurs, sait on jamais, si on veut controler le set du device par exemple. Enfin, c est tres bien comme tu as fait aussi.

Sinon le fait d avoir un device statique ne pose pas de problemes ? Par exemple si on construit un buffer avec un device et qu ensuite on change ce device ? Que se passe t il ?

Concernant dxut (que je ne connait pas, j imagine que c est un peu comme un glut version directX), quelle incidence ca a sur le code des renderers ? J aurai pense qu une lib utilitaire comme ca n allait changer que le code des demos mais dans un post precedent tu parles de modification dans le DX9Renderer pour integrer dxut.

donc pour le device, je n'ai jamais rencontrer de code qui utiliserait plusieurs device, tout ce que je suis sur, c'est que les index/vertex buffers (et autres) sont liés à un seul et unique device.

je n'ai pas mis le device dans le renderer parce que le renderer et les index/vertex buffers en ont tous besoin, j'ai choisi l'accessibilité à tous, je regarderai si y a des solutions plus propres.
si je garde cette solution, je vais rajouter des accesseurs, j'ai pas le réflexe d'en mettre.

il est vrai qu'une classe utilitaire pour dxut (qui est comme tu l'as dit un pendant de glut) serait plus logique. à cela une objection, du au fonctionnement même de dx9, fait que le code prévu pour dxut serait utilisable même sur une appli ne se servant pas de dxut. je regarderai ça plus longuement pour voir s'il est mieux de laisser comme ça ou pas.

mise à jour de l'archive

Salut,

j ai jete un coup d oeil.

Une petite remarque :
Concernant l'index buffer dans le quad renderer, tu ecrases les valeurs a chaque rendu. Or je ne pense pas que ce soit necessaire, l'index buffer etant statique.
En fait le best ce serai de le creer et l'initialiser avec les bons indices pour la totalite du buffer dans le createbuffer (un peu comme pour les coordonnees de textures qui sont statiques dans certains cas).
Ensuite tu ne fais que utiliser l index buffer sans y toucher lors du rendu et du coup tu peux specifier a directX que le buffer est statique comme ca il sera stocke cote GPU. Ca optimisera pas mal et le processing des vertex et la quantite de donnee transitant sur le bus.

[edit]
D ailleurs je vois que tu n a pas sette les hints lors de la creation de tes buffers et les lock (donc pour l instant les buffers sont consideres comme etant statiques). Le plus optimise pour les vertex et color buffers seraientt sans doute du DYNAMIC WRITE ONLY avec un lock en DISCARD. Les tex coord buffer peuvent etre statiques uniquement dans le cas de TEXTURE_2D sans atlas et le lock ne doit pas etre en DISCARD dans le cas de TEXTURE_3D sans atlas (comme les valeurs des composantes uv doivent etre conservees).
http://doc.51windows.net/Directx9_SDK/?url=/Directx9_SDK/graphics/reference/d3d/constants/d3dusage.htm
http://doc.51windows.net/Directx9_SDK/?url=/Directx9_SDK/graphics/reference/d3d/constants/d3dlock.htm

j'ai passé le remplissage de l'index buffer dans la fonction de création des buffers.

quant aux options d'usage et de lock, je vais profiler le code, on verra bien pour les perfs.

Comme ce sont juste des hints, en fonction de tes drivers GPU il peut ne pas y avoir de differences.
En tout cas si tu fais du profiling, fais le avec une grande quantite de quads tout petits histoire que ce ne soit pas le fillrate qui limite les perfs.

mouais bon le profiling ne donne pas grand chose, va falloir que je vérifie sur mon autre pc ><

mise à jour ce soir, je vais continuer de nettoyer ça.

Hello,

bah normalement bien setté les hints pour le stockage des buffers devrait quand meme faire une différence mais pour des petits systèmes de particules c'est peut etre négligeable. Ca devrait se ressentir pour des gros systèmes par contre. Apres tout depend de ton GPU.

Sinon j'ai mis en ligne la pré version 1.04 de SPARK. En gros ce qui change principalement pour les renderers c'est qu'il y a pas mal de factorisation de code. Par exemple l'orientation des quads est déporté dans une classe commune et n'a plus a etre implémenté par API de rendu.

La cette version est quasiment prete et je vais la sortir comme ca je pense. Je rajouterai les renderers Direct3D9 dans la version suivante quand tout sera pret.

ok, ça laissera le temps te finir les renderers manquants

ps: outch, y a un paquet de changement ><

stardeath wrote:

ps: outch, y a un paquet de changement ><

Oui pas mal . Mais en fait comme je l ai dit c est essentiellement de la factorisation de code donc c est plus des trucs a retirer a priori. En fait le developpement de 2 module de rendu en plus m a permis d extraire une interface commune pour les renderers. C est cense rendre l implementation de nouveaux renderers plus simple et garantir une certaine homogeneite.

Desole pour tout ces changement mais comme la lib est jeune, j essai de l ameliorer au fur et a mesure et ca passe par des changements dans l interface. Si t as pas le temps, je peux adaptater ton code a la nouvelle version si tu veux.

c'est juste que visual me sors une tartine d'erreurs, ça fait assez peur

renderers dx9 actuels à jour, plus qu'à finir les autres.

par hasard tu n'as pas un svn ou autre pour ce projet?

J'ai créé un SVN. Tu peux y uploader les renderers directX si tu veux.

renderers dx9 uploadés sur le svn

Ouais j'ai vu ca. J'y jeterais un coup d'oeil quand j'aurais un peu de temps et je te tiens au courant. Merci beaucoup

bon je suis emmerdé pour le DX9LineRenderer, il n'y a aucune manière de dessiner des lignes comme dans opengl, je suis obligé (sinon j'ai pas encore trouvé comment) de passer par des quad, le problème étant l'épaisseur sous opengl est défini en pixel écran (il me semble) et il va falloir trouvé comment émuler ça sous dx.

la manière que j'ai trouvé pour l'instant étant de changer l'épaisseur dynamiquement de chaque ligne en fonction de la distance à la caméra, mais qui dit distance dit racine carrée, et là ça devient embêtant vu le cout de calcul.

Bah t embete pas, toutes les lignes ont une epaisseur de 1 en direct3D et puis voila (c'est comme ca avec le module Irrlicht quand on rend en mode D3D9)

Sinon apparemment le seul moyen d'avoir des lignes avec une epaisseur est d'utiliser D3DX : http://msdn.microsoft.com/en-us/library/ee421991.aspx.

j'ai testé ce truc, ça fait que des linestrips, pas de line list, bon je mettrai dans ce cas ligne simple et quad, tant pis

état d'avancement :

renderer fini (ou presque) :
- Point
- Quad
- Line
- LineTrail

tout ça en cours de test et de profilage, ensuite faudra que je nettoie le code et que je le commente un minimum