La version 2.2 de NeoAxis 3D est disponible
Le moteur de jeux vidéo en C# se voit doter d'un outil d'analyse de performance
Le 2014-08-20 13:22:11, par LittleWhite, Responsable 2D/3D/Jeux
Le moteur de jeux vidéo, multi-plateforme, en C# atteint la version 2.2. Même si c'est une mise à jour mineure, celle-ci apporte :
- Physique des personnages : refonte complète du code de la physique des personnages ;
- Physique des personnages : ajout du support de la position accroupie ;
- Ajout d'un outil d'analyse de performance dans l'éditeur de carte. L'outil fournit des informations détaillées sur les composants du moteur, l'utilisation des ressources et des statistiques sur le rendu des images ;
- Ajout du type RenderableCurve. Les RenderableCurve permettent d'afficher des courbes épaisses et ayant un matériel ;
- Ajout du type ParticleSystemSource. C'est un objet spécial utilisé pour ajouter des systèmes de particules sur la carte ;
- support de WPF : optimisation de performance : ajout du support de D3DImage. D3DImage permet une nouvelle interopérabilité entre WPF et DirectX permettant ainsi de mélanger une surface personnalisée Direct3D avec une surface WPF native Direct3D ;
- support de WPF : gestion correct de l'événement "Device lost" du widget WPF ;
- PhysX : les corps cinématiques sont maintenant supportés. Quelques fois, le contrôle d'un acteur avec juste les forces et les contraintes ne suffit pas (pas assez robuste, précise ou flexible). Par exemple, le déplacement de plateformes ou de personnage nécessite souvent de jouer avec une position d'acteur ou de suivre un chemin spécifique. Ce type de contrôle est fournit avec les acteurs cinématiques ;
- PhysX : ajout de la possibilité de débloquer les axes de mouvement pour la jointure rotule. Nouvelle propriétés : PhysX_MotionLockedAxisX, PhysX_MotionLockedAxisY, PhysX_MotionLockedAxisZ ;
- Arbre d'animation : ajout de l'option de bouclage dans le block source ;
- Arbre d'animation : correction du block de transition ;
- Correction de bogue : Système sonore : calcul de l'atténuation de mouvement qui ne fonctionnement pas correctement ;
- Correction de bogue : Éditeur de carte : impossibilité d'exécuter un code C# compilé dans certains cas ;
- Correction de bogue : batching statique : bogue avec les matériels.
Vous pouvez télécharger la nouvelle version du moteur sur la page officielle.
Votre opinion
Source
Annonce officielle
-
I_PnoseMembre chevronnéNon ton jeu ne va pas freezer (ou alors il a un sérieux souci d’allocation d’objets). Grossièrement une collection de génération 0 prend entre 0 et 9ms, soit au pire la moitié de ton budget pour la mise à jour et le rend d’une seule image. bref si les collections sont maîtrisées ça passe inaperçu.
Cela dit, le GC est certainement l’un des principaux facteurs qui fera qu’un jeu développé en C# sera moins performant qu’un jeu développé en C++ (ou tout autre langage qui laisse la main sur la mémoire). Mais cette différence est tout de même pas si énorme que ça ; une routine écrite en C#/SharpDX sera en moyenne 1.2x plus lente que la même routine écrite en C++/DirectX.
Pour limiter les effets du GC il faut tout simplement éviter de le solliciter. Ça passe par exemple par l’utilisation de pools d’objets pour éviter les allocations (sur le tas) dans la boucle de jeu, éviter les foreach sur les collections qui implémentent IEnumerable, etc...le 21/08/2014 à 15:10 -
guillaume07Débutantc# pour le jeux video ?!le 21/08/2014 à 8:16
-
LittleWhiteResponsable 2D/3D/JeuxOui, ce n'est pas nouveau. Y avait déjà XNA, MonoGame, SharpDX, OpenTK ...le 21/08/2014 à 9:08
-
guillaume07Débutantet quand le GC passe, le jeux freeze ?le 21/08/2014 à 11:58
-
dfiad77proMembre expérimenté
ça c'est surtout lié au politique de développement métier,
si tu développe un jeux complexe direct en WPF Pure avec le refresh par zone, ça va lagger
Le but des moteurs C# est de permettre de développer un jeux avec un moteur performant
et de ne pas être trop limité par les performances des frameworks graphiques actuel qui sont fait pour l'applicatif.
Perso avec les surfaces direct3D incluse dans WPF on est a de très bonnes perfs,
même si programmer un jeu est rudement compliqué lorsqu'on est habitué à programmer de l'applicatif métier...le 21/08/2014 à 12:42 -
jean_kevin_musclorInactifle 22/08/2014 à 1:42
-
micka132Expert confirméSi finalement il faut faire attention à ne pas solliciter le GC, n'est ce pas aussi "pénible" que de se taper la gestion de la mémoire à la main?
J'y connais pas grand chose en jeux vidéo, et encore moins en c++, du coup si je veux me faire un petit jeu je partirais sur ce genre de solution, mais pour un pro y a t-il un avantage à utiliser du c#?le 22/08/2014 à 9:31 -
I_PnoseMembre chevronnéUn pro peut tout à fait utiliser le C# en tant que langage de script, mais les composants bas-niveau seront généralement développés en C++ (c’est le cas de Unity par exemple, qui est développé en C, C++ et Vala, alors que la partie script se fait en C#, JS, ou Boo). Bref, ça c’est plus ou moins la règle dans l’industrie AAA.
L’utilisation d’un wrapper DirectX comme SharpDx (ou OpenGl via OpenTK par exemple) permet toutefois de développer un moteur ou un Framework de jeu entièrement en C# (et de ce que j’ai compris c’est le cas ici avec NeoAxis), en gros le C# sera utilisé pour la plomberie du moteur ainsi que pour le scripting du jeu. L’inconvénient c’est qu’un deuxième boulet entre en compte (le premier étant le GC), c’est les changements de contexte managé/non managé ; ceci a un cout qui peut difficilement être gommé (puisque le moindre appel à l’API va nécessiter un changement de contexte).
Pour te répondre, certains pro n’auront pas besoin de la puissance de frappe d’un moteur de jeu triple A et pourront tout à fait opter pour une solution full C# (Terraria a été développé avec XNA par exemple, FEZ et Armed! avec monogame).le 22/08/2014 à 10:14