Discussion :

[lakitrid]

Je me suis empressé de visiter ton portail présentant ton projet que je suis depuis ton premier post sur le forum

La partie avancement est assez sympatique. J'éspere que tu aura le temps de le maintenir à jour, surtout la partie documentation / tutorial.

j'ai voulu acceder aux vidéo et en clicquant sur les images leur correspondant je me retrouve devant un jolis Not FOUND

[funkydata]

Salut, j'ai corrigé le problème des vidéos merci de me l'avoir signalé.

Pour la partie avancement il n'y aura aucun problème de mise à jour puisque je me suis fait un plugin qui me permet de mettre à jour cette partie du site directement depuis l'ide visual studio ...

Pour les tutoriaux, ils sont en préparation. Et j'espère en sortir régulièrement afin de bien documenter le projet. En effet, cela me semble essentiel à son épanouissement au sein d'une communauté.

[Tarul]

Bonsoir,

je viens de découvrir le projet(merci la page d'accueil de developpez.com ). A 1ere vu il a l'air d'être simple(mais vu que je n'ai aucune connaissance, mon jugement ne vaut pas grand chose ), mais les vidéos en ligne m'ont déjà fait forte impression.

Bref bon courage et bon chance pour le développements d'nxEngine.

[funkydata]

Bonsoir,

je viens de découvrir le projet(merci la page d'accueil de developpez.com ). A 1ere vu il a l'air d'être simple(mais vu que je n'ai aucune connaissance, mon jugement ne vaut pas grand chose ), mais les vidéos en ligne m'ont déjà fait forte impression.

Bref bon courage et bon chance pour le développements d'nxEngine.

Merci bien
Le nxEngine se veut, en effet, simple au niveau de l'approche, afin de permettre au plus grand nombre de tester la 3d temps réel sans connaissance particulière dans le domaine. Maintenant il est certain que les habitués de la 3d pourront faire des scènes beaucoup plus belles, beaucoup plus rapides et beaucoup plus complexes car tout ne peut pas être managé

[lougne]

beaucoup plus rapides et beaucoup plus complexes car tout ne peut pas être managé

il faudra un jour qu'on m'explique pourquoi, parceque je suis devenu un addict des programmes avec completion. Au point où en utilisant Render Monkey, j'étais presque déçu de ne pas avoir ce genre d'outils pour m'aider à écrire mes premiers pas de HLSL . C'est tuant , pour connaître les possibilitées de paramétrages pour un vertex par exemple, j'ai du chercher un code utilisant le xxx.position ou xxx.color et j'en passe pour savoir qu'ils existent. Je ne sais pas ou je pourrais trouvais une table pour le HLSL donnant la liste compléte ds propriétés de ce langage ( en tableau de préference)

edit: je viens de voir un ptit script pour notepad++ qui posséde les fonctions hlsl je regarde ça de prés

[funkydata]

il faudra un jour qu'on m'explique pourquoi

Le principal problème est bien évidemment une question de performances. Si tu prends un des shaders du nxEngine, il va devoir gérer pas mal de chose... Prenons l'exemple du calcul de la lumière (pour faire simple). Le shader va devoir faire quelques tests afin de la rendre convenablement : La scène a-t-elle une lumière omni directionnelle, directionnelle ? Est-ce qu'on lui applique une attenuation ? Son intensité est-elle variable... Tous ces tests sont indispensables aux shaders génériques implémentés dans le moteur car ils devront s'adapter à toutes les situations de scènes possibles.
Si tu créé ton propre shader pour ta scène, tu supprimes par la même tous les tests et opérations inutiles et donc fatalement tu gagnes en performance.

Aprés il y a d'autres raisons plus "philosophiques" qui rentrent en ligne de compte ...

[lougne]

oui, j'ai fouillé et on me parle toujours des critéres du nombre d'appels, le natif et autres. Mais est ce que la puissance de calculs des nouveaux processeurs ne nivelles pas les performances vers le haut au point où il y aurai aucune différence entre du code managé ou non.

En fouillant encore le critére qui revient est toujours le poids des données à traiter, est ce que en codant de maniére subtil et surtout grâce au multithreading on ne peut pas gérer ce flux de données.
question: ton moteur prévoit-il de gérer le multi-threading?

Pendant mon stage de testeurs de jeu à Ubisoft montréal en 2004, j'ai remarqué que les programmeurs utilisent tellement de libraries qu'on aurait pu croire qu'ils utilisent Managed C++, pourtant c'est du developpement en interne avec du C++ en dure et Unreal Engine.
Je suis devenu un accros de tout ce qui est ordonné avec ma formation individuelle parceque je cherchais toujours le meilleur bouquin pour le DotNet (Code complete, design patterns, ..) que le C++ à la dure je ne veus plus y toucher (ah merci Nunit) ; le meilleur outils de débutant qui veut voir les résultants tout de suite lol

[funkydata]

oui, j'ai fouillé et on me parle toujours des critéres du nombre d'appels, le natif et autres. Mais est ce que la puissance de calculs des nouveaux processeurs ne nivelles pas les performances vers le haut au point où il y aurai aucune différence entre du code managé ou non.

Clairement non, en tout cas pas dans ce genre d'application. Ceci dit je ne citais pas le "code managé" comme "le code c#". Je parlais du management au sein même du moteur.
D'ailleurs à ce propos je voulais dire parceque c'est une idée faussement répandue : le C# n'est pas un langage managé. Le code est compilé !

Ceci étant dit je crois que tu sous estime largement l'impact que peux avoir des tests ou des opérations superflues. Dans le domaine d'application standard tout cela ne se voit pas mais en 3d temps réel, il faut trés trés attention.

Il y a un moment, je fesais quelques tests de performances... j'ai remarqué notamment sur une scène composées de 1000 objets que calculer la boite englobante de chacun d'entre eux "coutait" 100 fps / 350 Aprés diverses optimisations j'ai pu descendre ce chiffre fort heureusement

Pour les shaders ce qu'il faut bien savoir c'est que si tu ajoutes une instruction supplémentaire dans le pixel shader celle ci va être exécuter autant de fois qu'un pixel sera afficher. Imaginons donc que tu doives afficher 256x256 pixels (ce qui est ridicule) tu arrives à 65536 instructions suplémentaires. Maintenant disons que tu as une cinquantaine de ces "objets" à calculer tu arrives à 3276800 instructions supplémentaires par frames... Alors bien sur plus le GPU est puissant moins la différence sera grande mais elle sera quand même présente... et l'exemple utilise des chiffres extrèmements bas. Il faut donc faire trés attention à ce genre de chose.

En fouillant encore le critére qui revient est toujours le poids des données à traiter, est ce que en codant de maniére subtil et surtout grâce au multithreading on ne peut pas gérer ce flux de données.
question: ton moteur prévoit-il de gérer le multi-threading?

C'est une question que je me suis posée sans aller plus loin que cela. Ceci dit, le multithread c'est vraiment le bordel à gérer au niveau du rendu... Aprés c'est certain que cela pourrait être un plus appréciable pour notamment le chargements des ressource... ou mieux, si on veut faire du streaming in game. En tout cas pour l'instant ce n'est pas d'actualité

Pendant mon stage de testeurs de jeu à Ubisoft montréal en 2004, j'ai remarqué que les programmeurs utilisent tellement de libraries qu'on aurait pu croire qu'ils utilisent Managed C++, pourtant c'est du developpement en interne avec du C++ en dure et Unreal Engine.

Logique... je vois pas en quoi cela te surprends. Le code managé ne se défini au nombres de librairies que l'on utilise mais plutôt sur quelles couches système ces libraries reposent...

[Smallpox]

J'aimerais comprendre une des phrases que tu as dit plus haut.

"D'ailleurs à ce propos je voulais dire parceque c'est une idée faussement répandue : le C# n'est pas un langage managé. Le code est compilé !"

le C# est un langage managé quant tu utilise le framework .NET ( ce qui est le cas je pense ) puisque la définition même de managé est "étant géré par la CLR .NET )...
Bien sur, tu peux faire du C# non managé mais dire que le C# est pas un langage managé est peu être un peu poussé.( < 5% de ses cas d'utilisations et il n'a jamais été fait pour ca)
De plus,je pense que ton moteur est principalement en code managé.

"Le code est compilé" : oui et non.
Le code est compilé une premiere fois en MSIL au moment de la génération de l'exe puis recompiler en temps réel par la CLR au moment de l'éxecution.

Le mot compilé se trouve deux fois dans la définition mais ce n'est pas pour ca que ca correspond à une véritable compilation du C++ ( qui écrit directement son code en langage machine et n'a pas besoin de machine virtuelle).

Dire que le C# est compilé voudrait dire que ca génère un exe directement en code machine et qu'il n'aurait pas besoin de machine virtuelle.
Dire que le C# est compilé voudrait dire que Java est un langage compilé ...

J'ai peut être mal compris tes propos ( dans ce cas hésite pas à me corriger ).

Niveau perf, même si l'écart commence à se réduire, les langages de type C# et Java reste les plus lent et les plus gourmand à cause de leur machine virtuelles... maintenant cette petite machine virtuelle rend tellement de service qu'on aurait tort de s'en priver

[funkydata]

Bon alors je vais essayer d'être clair cette fois Je peux me tromper, j'ai pas la science infuse et C# je ne connais que depuis 7 mois... mais ce que l'on m'a expliqué est la chose suivante :

Code -> Compilation -> IL Code

Puis à l'exécution :

IL Code -> JIT Compiler (CLR) -> Code Natif -> Execution

Donc d'aprés ca le c# est bien un code compilé puisque la finalité est du code natif. Certes le code natif n'est obtenu qu'aprés la compilation JIT (c'est à dire au lancement) mais une fois l'appel fait, le JIT ne doit plus être appelé puisque l'on reste en règle générale dans la même assembly.
Par contre je suis d'accord sur le fait, qu'à la compilation, tout un tas de choses superflues (ou trés utiles tout dépend ) vont être automatiquement ajoutées et que dans certains cas cela va ralentir le tout... en ca on peut dire que c'est un langage managé car sur bien des points il "aide" le programmeur en générant son propre code (ce que ne fait pas bien entendu un compilateur c++ ) GC...

Donc pour résumé oui c'est un langage managé car il aide le programmeur et part là même ajoute tout seul pas mal de choses au code en lui même. Mais finalement non car la compilation finale effectuée par le compilateur JIT au lancement produit un code natif qui sera utilisé sans nouvel appel au compilateur pour peu que l'on reste dans la même assembly.

Pour info aussi le nxEngine utilise du code "unsafe" (environ 5-10%).

Enfin j'ajouterais qu'a l'origine du post je ne parlais pas de "code managé" mais des "fonctions managées" du moteur... car même si il s'avère que je me trompe et que le c# est un langage managé je n'ai pas l'intention de revenir à cette affreux c++ ... qui m'a rendu quand même de fier service pendant les 8 dernières années

[Smallpox]

Oui c'est clair que c'est un peu joué sur les mots je l'avoue ...Mais je suis d'accord avec ta seconde explication .

pour le moteur en unsafe, c'est clair que pour du temps réel en C# tu dois obligatoirement avoir pas mal de parti unsafe ( j'ai moi même fait un logiciel de traitement vidéo temps réel et j'étais obligé de mettre tout ce qui était "traitement" / "filtres" en unsafe pour accélerer le truc. ( d'ailleurs au final j'ai carrement mis la vidéo sur une face 3D et j'ai écrit les filtres vidéos en .... shaders )

[funkydata]

Oui le code unsafe est un gros plus... je pense que le moteur en aura pas mal à terme même si j'essaye dans un premier temps de na pas trop en mettre pour améliorer la lisibilité du code.
Ensuite lorsque le moteur commencera à avoir de la "bouteille" il est certain que pas mal de fonctions hériteront d'un p'tit "unsafe"

[wizad]

Je me permettrais d'ajouter à cette discussion sur le c# que à la différence du Java il n'est pas complètement compilé en temps réel : en réalité, lors du premier accès à une méthode celle-ci est compilé. Puis par la suite les accès ultérieur utilise la version déjà compilé (en cache) ce qui permet au code d'avoir des performance tout à fait raisonnable. De plus la compilateur (JIT) disposant de nombreuse information sur l'état du système et ses capacité peut générer toutes sorte d'optimisation du code permettant encore d'améliorer les performance.

[sinok]

Je me permettrais d'ajouter à cette discussion sur le c# que à la différence du Java il n'est pas complètement compilé en temps réel : en réalité, lors du premier accès à une méthode celle-ci est compilé. Puis par la suite les accès ultérieur utilise la version déjà compilé (en cache) ce qui permet au code d'avoir des performance tout à fait raisonnable. De plus la compilateur (JIT) disposant de nombreuse information sur l'état du système et ses capacité peut générer toutes sorte d'optimisation du code permettant encore d'améliorer les performance.

Sans vouloir troller, java c'est la même (JIT et tout le toutim)

[wizad]

Autant pour moi il me semblait que l'implémentation était différente (avec notamment une recompilation systématique à chaque appel). Enfin jusqu'à présent le c# s'est révélé généralement légèrement plus rapide que du java. Bref faudrais pouvoir mettre le nez dans les différents système pour pouvoir déterminer les meilleur choix.