Le moteur C# NeoAxis 3D 2.0 est disponible

Je suppose que lorsque tu parles de Mono, tu fais allusion à Monogame. Ce dernier n’est pas un moteur de jeu, selon moi, mais davantage un Framework de jeu. Du coup je ne pense pas qu’on puisse les comparer aussi facilement :

D’un côté on a un ensemble d’outils (éditeur de map, éditeur de matériaux, physique, etc...), une interface dédiée qui permet de scripter des objets prédéfinis/d’appliquer des comportements (ou de créer ses propres objets/comportements, rapidement, via un langage de programmation) et de l’autre on a une surcouche sur l’API Graphique (DirectX ou OpenGL suivant la plateformes visée) permettant d’abstraire la création et la mise-à-jour du contexte graphique et le chargement des assets... il n’y a pas grand-chose de plus (si on veut créer un terrain de 3km² avec LOD dynamique, on se le code, si on veut de la physique, on se la code, et plus globalement si on veut créer un jeu vidéo il est nécessaire de se créer une surcouche par-dessus le Framework -éléments affichables, gestionnaires, etc...). Clairement, un moteur de jeu permet de s’affranchir de toutes ces étapes en donnant des solutions clé en main (plus de code HLSL/GLSL on a un éditeur de matériaux, le placement des objets se fait en temps réel via l’interface, on a une bibliothèque de composants afin de créer des interfaces, etc...).

Tu vas me dire que tu préfères tout faire toi-même manuellement, mais dans la réalité un studio de jeux un tant soit peu sérieux ne s’amusera pas à réécrire la roue (sauf quand on s’appelle Dice et consort) et passera par un moteur de jeu. Après, Il faut savoir ce qu’on veut ; faire du jeu vidéo, ou un moteur de jeux vidéo.

Pour en revenir au sujet, Il manque encore quelques arguments à ce NeoAxis pour faire de l’ombre à Unity3D ou UDK (pas de support multiplateforme parmi les différences les plus notables). Cela dit, le moteur a au moins le mérite d’ouvrir ses sources... si on y met le prix.

En complément, on pourrait surtout dire que l'outil manque encore cruellement d'ergonomie, même si la version 2.x apporte de réelles améliorations.
Dommage, car le moteur est intrinsèquement plutôt bon, même si quelques manque se font encore sentir (Deferred Rendering, etc...)....

c# pour le jeux video ?!

Oui, ce n'est pas nouveau. Y avait déjà XNA, MonoGame, SharpDX, OpenTK ...

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...

Je suis d'accord avec ça.

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#?