Developpez.com - Rubrique 2D-3D-Jeux

Le Club des Développeurs et IT Pro

La version 2.1 de NeoAxis 3D est disponible

Une mise à jour mineure apportant des corrections de bogues et le groupement statique de géométries

Le 2014-02-03 21:55:03, par LittleWhite, Responsable 2D/3D/Jeux
Cette nouvelle version est une mise à jour mineure de la version 2.0. Même si elle ne rajoute pas de grandes fonctionnalités, la liste des modifications reste intéressantes :

  • amélioration des comportements physiques et des animations des personnages ;
  • ajout des versions 32 bits pour l'éditeur de cartes et l'éditeur de ressources ;
  • correction du comportement avec les chemins de fichiers invalides pour les fichiers de squelettes ;
  • changement de la gestion des entrées pour certains événements de l'interface ;
  • la liste des assembleurs de références peut être configurée dans l'éditeur logique et non plus uniquement par le fichier Data\Base\Constants\EntitySystem.config ;
  • amélioration du code C# généré par l'éditeur logique ;
  • correction de la compilation du SDK avec Visual Studio 2012 et supérieur ;
  • ajout d'un paramètre d'inversion des normales pour l'exporteur 3DS Max et l'importeur.


De plus, cette version apporte le regroupement statique des géométries. Cela permet des améliorations sur le rendu et la physique. La fonctionnalité ne fonctionne que sur les modèle statiques (StaticMesh)



Votre opinion

Avez-vous essayé ce moteur ? Qu'en pensez-vous ?
  Discussion forum
14 commentaires
  • I_Pnose
    Membre chevronné
    Envoyé par guillaume07
    et quand le GC passe, le jeux freeze ?
    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...
  • guillaume07
    Débutant
    c# pour le jeux video ?!
  • LittleWhite
    Responsable 2D/3D/Jeux
    Oui, ce n'est pas nouveau. Y avait déjà XNA, MonoGame, SharpDX, OpenTK ...
  • guillaume07
    Débutant
    et quand le GC passe, le jeux freeze ?
  • dfiad77pro
    Membre expérimenté
    Envoyé par guillaume07
    et quand le GC passe, le jeux freeze ?

    ç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...
  • Envoyé par I_Pnose
    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...
    Je suis d'accord avec ça.
  • micka132
    Expert confirmé
    Envoyé par I_Pnose
    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...
    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#?
  • I_Pnose
    Membre chevronné
    Envoyé par micka132
    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#?
    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).