DCS 1.5 en septembre (avec Edge)

[Ex Machina]

Conclusion, faut optimiser le code !!

++

[phoenix]

On est donc bien d'accord. La question n'est pas que de refaire le code en optimisant pour le multithreading n'apporterait pas de perfs en plus mais que cela reviendrai à refaire trop de choses et coûterait trop cher.

Non, ca serait juste logique pour un jeu de 2015 que l'on veut remettre à neuf et que l'on veut pouvoir faire évoluer dans le temps. Là, on reste sur une technologie de plus de 10 ans qui montre ces limites, et on fait rien pour y remédier. Bref, on continue à faire croire que l'on fait du neuf en mettant des bouts de pansement sur du code antédiluvien. Oui, ça coute de l'argent, mais à un moment, il n'y a pas le choix si on veut s'inscrire dans la durée, tout en utilisant des technologies actuelle.

En même temps il faut se mettre du coté d'Eagle Dynamic. Le contenu évolue et le jeu est maintenu depuis des années mais les joueurs ne payent quasiment rien (DCS world est gratuit, et les modules sont si souvent en promo qu'en tout j'ai pas du dépenser plus de 50$ chez eux pour FC3, A-10C, F-86, Combined Arms...). Je comprends qu'ensuite ils rechignent à faire des énormes MàJ sans redemander de payer. Et la tu parles de refaire quasiment un jeu en reprenant 0% du travail fait.

Le prix des modules, c'est eux qui le fixe, et leur promos, ce sont eux qui les fixes. Le problème, c'est que tous les 3 mois, tu as une promo. Si tu suis l'actualité, et sauf si tu veux un module à sa sortie, tu sais que tu attends entre 3 et 6 mois, et tu as les premières promos, puis le produit qui se retrouve dans la case des grandes promo tous les 2/3 mois. A force de faire trop de promo, les joueurs ont compris, et attendent. Pour parler de mon cas, le MiG 21 m'interressait mais pas au point de le prendre à sa sortie. J'avais d'autres jeux au moment de la sortie, et je n'aurais pas pu m'y consacrer. De plus, je savais qu'en attendant je l'aurais en promo, donc tout bénef pour moi d'attendre. Je l'ai pris, mais pas au prix fort (et je n'y ai toujours pas joué).

Et on ne va pas parlé des mises à jour que l'on a repayé FC1, FC2, FC3.

De plus, ça fait pas mal d'année qu'il ne font pas du vrai neuf, donc à un moment les gens en ont marre. On leur promet des choses, et rien n'arrive, juste des retards. Il ne faut pas s'étonner que les gens deviennent frileux. A force de s'endormir, c'est comme ça que l'on disparait. Ce ne serait pas les premiers acteur majeurs à disparaitre du jour au lendemain (Kodak, etc...). La chance qu'ils ont, c'est que l'on ait sur un marché de niche sans réelle concurrence, mais à un moment, ça ne veut pas dire qu'il ne faut pas évoluer.

@ Sedenion : Concernent l'utilisation du multicoeur, il y a bien des jeux qui l'utilisent, et il y a deux simulateurs qui en profitent, mais il partagent le même moteur. Il s'agit de Rise of Flight et de IL2 Battle of Stalingrad. Sur certains points, le multicoeur ne va pas impacter, mais sur d'autre, c'est un plus. Tu vas pouvoir gérer plus d'IA, ce qui veut dire, mouvement, détection, etc, et ce en limitant l'impact sur les FPS, ou en limitant la puissance du CPU, voir les deux.

[sedenion]

@ Sedenion : Concernent l'utilisation du multicoeur, il y a bien des jeux qui l'utilisent, et il y a deux simulateurs qui en profitent, mais il partagent le même moteur. Il s'agit de Rise of Flight et de IL2 Battle of Stalingrad. Sur certains points, le multicoeur ne va pas impacter, mais sur d'autre, c'est un plus. Tu vas pouvoir gérer plus d'IA, ce qui veut dire, mouvement, détection, etc, et ce en limitant l'impact sur les FPS, ou en limitant la puissance du CPU, voir les deux.

Ouais, pour l'IA à la limite effectivement, où on peut se permettre d'avoir quelques millisecondes de retard, mais ça doit être un sacré casse-tête à mon avis...

[phoenix]

Ca me fait pensait que lors de la sortie de Blackshark (si ma mémoire est bonne), on utilisait des utilitaires pour forcer l'execution sur plusieurs coeurs pour gratter quelques FPS.

Que ce soit un casse tête, peut être, peut être pas (c'est peut être aussi une question de compétence/formation), mais soit on se contente de programmer comme il y a 10ans, ou on s'adaptent, surtout sur des programmes gourmands. Quoiqu'il en soit, c'est pas le problème du client. Et on a pas à se contenter de ce qui se faisait il y a 10 ans, alors que la puissance de nos PC a trés largement augmenté, et que l'on est en droit d'attendre un plus.

[Ex Machina]

Et puis c'est leur taf aussi, alors se "casser la tête" c'est juste normal, sinon, effectivement, rien ne progresse.

++

[gilles41]

@ phoenix :

essai Bill2's process manager

[sedenion]

Que ce soit un casse tête, peut être, peut être pas (c'est peut être aussi une question de compétence/formation), mais soit on se contente de programmer comme il y a 10ans, ou on s'adaptent, surtout sur des programmes gourmands. Quoiqu'il en soit, c'est pas le problème du client. Et on a pas à se contenter de ce qui se faisait il y a 10 ans, alors que la puissance de nos PC a trés largement augmenté, et que l'on est en droit d'attendre un plus.

C'est un casse-tête quoi qu'il arrive. Vous savez pourquoi ils ont lancé les processeurs multicoeurs ? D'une part parceque ça fait un argument de vente un peu bidon, et d'autres part, parceque ça vise en réalité le marché des serveurs (serveurs web), qui eux, peuvent effectivement tirer partie du multicoeur, car les contraintes ne sont pas les mêmes et sont beaucoup plus faciles à gérer: Vous avez 1000 requêtes, vous pouvez en traiter 500 d'un coté et 500 de l'autre, ça ne pose aucun problème puisque chaque requêtes est unique et à usage unique... Mais quand il s'agit de faire tourner un jeu vidéo, qui est un système complexe où tout est interdépendant ET synchronisé, c'est un tout autre problème... Que certains moteurs aient réussi à paralléliser un ou deux modules (L'IA par exemple), au prix de certains effort, je veux bien le croire, mais je paris que le gain de performance est en fait minime... Et comme je vous ai dit: en réalité, contrairement à ce qui était vrai il y'a encore quelques années, le goulot d'étranglement c'est la carte graphique... car, certes les cartes sont plus en plus puissantes, mais les graphismes aussi sont de plus en plus détaillés. Et quand vous voyez un Su-27 à 300 000 faces avec 4 textures 2048*2048 avec un shader composite avec texture spéculaire et normal mapping et que vous en mettez quatre l'un à coté de l'autre sur l'écran, y'a pas de miracle...

[Ghostrider]

en meme temps le multi core ca permet de gerer d autres choses comme le multi
Voir BF4 avec un core 2 jouable en solo , injouable sans quadri
Donc si ed pouvait se servir des autres core qui se la coulent douce pour gerer la physique, le multi et les ia ca serait deja pas mal
Car rajouter des effet direct x ca fait pas un nouveau moteur

[sedenion]

en meme temps le multi core ca permet de gerer d autres choses comme le multi
Voir BF4 avec un core 2 jouable en solo , injouable sans quadri
Donc si ed pouvait se servir des autres core qui se la coulent douce pour gerer la physique, le multi et les ia ca serait deja pas mal

Si ils pouvaient se contenter de faire un vrai serveur dédié (sous linux svp) ça réglerait bien des soucis... Et sur un serveur dédié, là en effet, ils pourraient faire un programme qui tire partie du multicœur...

[Bacab]

@Sedenion, sur les jeux qui bénéficient du multithreading:
http://www.hardware.fr/focus/101/perfs- ... loupe.html
et les gains sont intéressants.

Pour ce qui est du goulet d'étranglement du GPU je n'y crois pas. Récemment ce qui m'a permis d'avoir des performances décentes sous DCS c'est le changement de mon processeur, pas le changement de CG (qui lui n'a rien changé).

Quand à la physique (au sens large de tout ce qui émule des mécanismes réels comme l’atmosphère, les radars... pas uniquement les collisions) il est difficile d'estimer sa complexité. Après tout on ne sait quels algorithmes sont choisis pour calculer les différents éléments. Il existe déjà 36 façons de faire calculer une intégrale à un PC qui varient du simple au triple en temps d’exécution alors simuler des conditions atmosphériques...

[phoenix]

@ phoenix :

essai Bill2's process manager

Je connais, c'est ce que j'utilise sur le serveur dédié à BoS.

Que ce soit un casse tête, peut être, peut être pas (c'est peut être aussi une question de compétence/formation), mais soit on se contente de programmer comme il y a 10ans, ou on s'adaptent, surtout sur des programmes gourmands. Quoiqu'il en soit, c'est pas le problème du client. Et on a pas à se contenter de ce qui se faisait il y a 10 ans, alors que la puissance de nos PC a trés largement augmenté, et que l'on est en droit d'attendre un plus.

C'est un casse-tête quoi qu'il arrive. Vous savez pourquoi ils ont lancé les processeurs multicoeurs ? D'une part parceque ça fait un argument de vente un peu bidon, et d'autres part, parceque ça vise en réalité le marché des serveurs (serveurs web), qui eux, peuvent effectivement tirer partie du multicoeur, car les contraintes ne sont pas les mêmes et sont beaucoup plus faciles à gérer: Vous avez 1000 requêtes, vous pouvez en traiter 500 d'un coté et 500 de l'autre, ça ne pose aucun problème puisque chaque requêtes est unique et à usage unique... Mais quand il s'agit de faire tourner un jeu vidéo, qui est un système complexe où tout est interdépendant ET synchronisé, c'est un tout autre problème... Que certains moteurs aient réussi à paralléliser un ou deux modules (L'IA par exemple), au prix de certains effort, je veux bien le croire, mais je paris que le gain de performance est en fait minime... Et comme je vous ai dit: en réalité, contrairement à ce qui était vrai il y'a encore quelques années, le goulot d'étranglement c'est la carte graphique... car, certes les cartes sont plus en plus puissantes, mais les graphismes aussi sont de plus en plus détaillés. Et quand vous voyez un Su-27 à 300 000 faces avec 4 textures 2048*2048 avec un shader composite avec texture spéculaire et normal mapping et que vous en mettez quatre l'un à coté de l'autre sur l'écran, y'a pas de miracle...

Pour le gain, ca permet juste d'avoir plus d'IA en l'air et de faire un peu moins vide genre FS X (ou de gérer d'autre chose, par exemple les collisions avec les arbres quand elles seront là, pour gérer une meilleur ligne de visé des IA, etc... ). Donc je n’appellerais pas ça minime. Et plus on aura d'IA en vol, au sol, plus ça permettra de faire des missions intéressantes. Donc, non le gain n'est pas négligeable pour moi.

DCS est à la ramasse graphiquement, c'est pas lui qui occupe nos cartes graphiques dernière génération. Va voir les nombre de polygone que peut afficher la dernière version du cry engine (star citizen) et les effets, tu vas pleurer sur les deux pauvres polygones affichés par DCS.

C'est bien le CPU le goulot d'étranglement. Ce n'est pas pour rien que les gens overclocke, c'est parce que ça se traduit par des FPS en plus. Et le multicrew ne va pas aider nos proco mono thread, enfin s'il sort un jours.

[terence44]

en meme temps le multi core ca permet de gerer d autres choses comme le multi
Voir BF4 avec un core 2 jouable en solo , injouable sans quadri
Donc si ed pouvait se servir des autres core qui se la coulent douce pour gerer la physique, le multi et les ia ca serait deja pas mal

Si ils pouvaient se contenter de faire un vrai serveur dédié (sous linux svp) ça réglerait bien des soucis... Et sur un serveur dédié, là en effet, ils pourraient faire un programme qui tire partie du multicœur...

Les serveur dédié arrive pour 2053 normalement

[sedenion]

@Sedenion, sur les jeux qui bénéficient du multithreading:
http://www.hardware.fr/focus/101/perfs- ... loupe.html
et les gains sont intéressants.

Hum, non, je suis très sceptique, et j'explique pourquoi:
1) d'une part (bien que je n'ai pas tout lu (c'est long hein)) je ne vois pas où il est noté que les jeux sont spécifiquement optimisés pour profiter du multithreading (ou hyperthreading ou ce que vous voulez), c'est donc mystère et boule de gomme
2) partant du premier constat, vu les gains assez relatifs de performance, il est fort à parier que c'est d'avantage une question d'optimisation générale des chipsets et des processeurs qui jouent, le tout modulé par le type de programme qui tourne: Certains programmes bien codés peuvent être plus facilement optimisés (profiter des caches CPU et ce genre de chose), certaines opérations peuvent être irréductibles ou au contrairement facilement paralélisables... Je vais prendre un exemple simple: Un jeu qui ne fait que des calculs simples, comme des multiplications sur des portions mémoires assez faibles, le matériel peut de lui-même optimiser et paralléliser les opérations, il peut envoyer par exemple (je dis ça au pif un peu) : trois multiplications d'un coté et trois multiplications de l'autre... par contre, si le programme est blindé de racine carré par exemple (genre d'opération mathématique bien coûteuse), il ne pourra pas diviser l'opération "racine carré" en deux pour diviser le temps de calcul...

Et pour appuyer mon propos, je citerais l'article:

"Sur AMD Vishera les performances sont doublées en passant de 2 à 4 cœurs, une configuration dans laquelle le jeu commence à être jouable aux réglages testés car au-delà du framerate bas on note de forts à-coups avec 2 cœurs. Le passage à 6 cœurs n'apporte par contre qu'un gain réduit, alors que bizarrement on gagne plus en passant à 8.
Pour ce qui est du goulet d'étranglement du GPU je n'y crois pas. Récemment ce qui m'a permis d'avoir des performances décentes sous DCS c'est le changement de mon processeur, pas le changement de CG (qui lui n'a rien changé)."

Il n'y a aucune raison, si le programme est réellement "optimisé" pour le multithreading, que les performances ne suivent pas une courbe linéaire avec le nombre de coeur... Aucune raison pour que ça marche mal à deux coeurs, deux fois mieux à 4 coeur, que ça ne change rien à 6 et que ça marche soudainement mieux à 8 coeurs... non, ça veut simplement dire que c'est le matériel, qui fait la différence, et qui est globalement, plus ou moins bien optimisé, et qui peut, plus ou moins bien répartir les opérations d'un coeur à l'autre, toujours selon la forme du programme qui est derrière. Pourquoi par exemple ça marche mieux à 2 - 4 ou 8 coeurs et pas à 6 par exemple ? parceque, par exemple (encore une fois, c'est un exemple schématique, ne le prenez pas au pied de la lettre) une matrice de transformation commune c'est un tableau de 16 flotants, et que 16, ça peut se divise facilement par 2, par 4 ou par 8, mais par 6 ça va être difficile, parce-que ça 16/6 ça fait 2.666666666...

Ensuite, vous pensez vraiment que ces moteurs ont 4 ou 6 threads ? Si ils en ont deux, ça sera déjà par mal à mon avis... dans le meilleur des cas, ils paralélissent certaines opération en utilisant soit OpenCL soit une variante, et comme je l'ai expliqué, ça se limite à une portion congru du code, les multiplications de matrice par exemple...

Je suis peut-être à coté de la plaque hein, je ne prétend pas tout connaitre, mais si vraiment ces jeux sont optimisés "multihreading", je suis curieux de savoir comment au delà de quelques truchements (comme la séparation de l'IA ou du module réseau) qui de toutes façons fonctionnent de manière asynchrone...

Quand à la physique (au sens large de tout ce qui émule des mécanismes réels comme l’atmosphère, les radars... pas uniquement les collisions) il est difficile d'estimer sa complexité.

Les calculs d'atténuation de l'athmosphère pour le radar par exemple c'est rien du tout du tout... (c'est l'équation d'atténuation de la lumière hein), c'est trois lignes de calcul mathématique, les radar idem: les moteurs de jeux sont déjà nativement conçus pour détecter les objets "visibles" ou non à travers des frustum (pour l'optimisation justement), ces calculs sont négligeables. Vous avez beaucoup plus de calcul dans le simple affichage d'une transformée de fourrier sur votre plugin winamp. Les choses gourmandes en calcul ne sont généralement pas là où on le pense. Même si ça parrait "impressionant" parceque ce sont des équations de physique, parfois complexes, qui mettent en jeu peut-être 5, 6 ou 7 variables, mais c'est RIEN ce ne sont QUE des équations, et ces calculs là, vous les faitent une fois pour UN avion, or, il n'y a pas 500 000 avions, il y'en a 10, 15, 30 tout au plus... Par contre, si vous devez faire un test de collision de particule sur un mesh qui a 300 000 triangles, ce qui comprend plusieurs produits scalaires de vecteurs (opérations simples, mais nombreuses), de soustractions, d'aditions, le tout multiplié par mettons 5000 particules (obus) dirigés vers 300 000 triangles à tester, ça fait ... une boucle de 1500000000 éléments à tester récursivement... voyez, c'est sur ce genre de cas que le CPU prend cher, et c'est aussi là qu'on peut parfois paralléliser (mais à quel prix, pour le moment du moins, si dans quelques années OpenCL se démocratise, et devient moins merdique à implémenter, qui sait).

Après tout on ne sait quels algorithmes sont choisis pour calculer les différents éléments. Il existe déjà 36 façons de faire calculer une intégrale à un PC qui varient du simple au triple en temps d’exécution alors simuler des conditions atmosphériques...

C'est rien du tout, je vous le dit moi... La complexité d'une opération joue, mais, à l’échelle de tout ce qui se passe dans un jeu vidéo, le calcul d'une équation d'atténuation c'est une molécule d'eau dans un océan... par contre, si vous êtes obligés de le calculer 1500000000 fois par "frame", là oui, ça peut faire mal...

[sedenion]

DCS est à la ramasse graphiquement, c'est pas lui qui occupe nos cartes graphiques dernière génération. Va voir les nombre de polygone que peut afficher la dernière version du cry engine (star citizen) et les effets, tu vas pleurer sur les deux pauvres polygones affichés par DCS.

Détrompez vous, Les modèles de DCS sont, pour certains maintenant, TRES détaillés... les derniers Su-27 et ce genre de chose, par exemple. Quand vous en avez un ou deux, c'est pas un problème, quand vous commencez en a en avoir 5 ou 6, ça commence à faire mal. Faites simplement le test : prenez une base, visez vos FPS "à vide"... vous reprenez la même base, et vous ajoutez quelques Su-27 en "statique" sur la piste (même pas des IA, hein, juste des statiques)... mettez en 5 ou 6... visez encore une fois les FPS quand vous les avez tous dans votre champs de vision...

Que les cartes graphique soient de plus en plus puissante c'est une chose, mais quoi qu'il arrive, quand vous arrivez au bout de ses limites, vous arrivez au bout de ces limites... alors ça tourne bien jusqu'à (au pif) un milliard de polygones, et puis quand vous dépassez ce seuil, et ben ça se met à ramer de plus en plus au force d'en ajouter, parceque la carte elle a un milliard de transistors, pas deux milliards, donc elle va devoir faire une "seconde passe" pour vomir le résultat.

On notera aussi sur DCS une nette baisse de performance lié à l'eau... car le shader (et je ne sais pas exactement comment il fait) est assez mastoc en mode détail, notamment il prend fait un reflet "miroir", ce qui, en général, veut dire: La scene est calculé DEUX fois, une fois pour l'eau, et une autre fois pour la totale... bon ben ça double le calcul graphique à effectuer mine de rien...

Après, que DCS roule sur du directX de vielle génération, pas adapté aux nouvelles capacités des cartes graphiques, c'est sans doute vrai aussi. Mais question "polygone", ça risque de ne pas changer grand chose, à moins que le moteur actuel soit VRAIMENT à la masse (ce qui est possible hein, j'en sais rien).

Après, l'autre aspect de DCS, et j'en avais déjà parlé, c'est le nombre d'objets... objets qui sont autant de choses dont il faut actualiser la position, autant de choses à "parcourir" dans le graph d'actualisation... et effectivement, là, c'est le CPU qui s'en charge. Alors en théorie, sur un moteur bien optimisé, on actualise que ce qui bouge... ça évite par exemple d'avoir à se retaper le calcul des 500 matrices des 500 maisons qui campent au sol à chaque frame... Est-ce que DCS optimise ça, ou est-ce qu'ils ont été assez naïfs pour forcer l'actualisation des objets statiques même si ils ne bougent pas ? Faut leur demander.

[Bacab]

Si tu lis bien l’article la conclusion c'est que la véritable augmentation se fait en passant de 2 à 4 cœurs et que le reste se fait dans la marge et cela pour certain jeux. Ensuite je ne vois pas de biais dans la méthodologie. Si en désactivant 2 cœurs tu obtiens de moins bonnes performances sur certains jeux et pas sur d'autre c'est bien que c'est au niveau du jeu et de la façon dont il est fait que la différence se fait. Il existe donc des jeux plus ou moins adaptés à exploiter de multiple cœur.

En ce qui concerne mon cas je suis resté au même nombre de cœur mais la fréquence et le nombre d'opérations par cycle de mon nouveau processeur sont plus importants que sur l'ancien. La où je voulais en venir c'est que c'est bien le processeur qui est limitant pour moi sur DCS et non la carte graphique.

Pourquoi je parlais de la physique de DCS, il y a pour moi deux situations possibles :
- soit DCS rame plus que les autres jeux car il fait plus de calculs (qui seraient du coup liés à la physique et au fait qu'il essaye de simuler plus de phénomènes réels que les autres);
- soit il ne fait rien de significativement plus impactant sur les performances que les autres jeux et en ce cas je me demande bien à quoi DCS utilise mon processeur.

Je veux dire entre The Witcher III et DCS qu'est ce qui justifie que dans un cas le GPU est limitant (et le CPU est assez peu sollicité) et dans le second c'est le CPU ? Soit DCS fait plus soit il a une manière singulière de gérer les graphismes.

PS: je ne comprends pas ton exemple sur la collision. C'est bien la preuve que de simuler de la physique c'est exigeant en terme de calculs ce qui était mon propos un peu plus haut ??

Et les modèles de simulation peuvent être très détaillés on en sait rien. J'ai travaillé avec des algorithmes qui prenaient 16*32 variables en entré (donc peanuts) et qui mettaient à genoux la machine sur laquelle je travaillais.

[sedenion]

Si tu lis bien l’article la conclusion c'est que la véritable augmentation se fait en passant de 2 à 4 cœurs et que le reste se fait dans la marge et cela pour certain jeux. Ensuite je ne vois pas de biais dans la méthodologie. Si en désactivant 2 cœurs tu obtiens de moins bonnes performances sur certains jeux et pas sur d'autre c'est bien que c'est au niveau du jeu et de la façon dont il est fait que la différence se fait. Il existe donc des jeux plus ou moins adaptés à exploiter de multiple cœur.

Oui ça dépend de la manière dont il est fait, mais pas nécessairement parcequ'il est spécifiquement multithreadé, c'est ça que je veux dire. Ils sont peut-être multithreadé, mais ce n'est marqué nulpart où et comment... Vous savez même d'un compilateur à l'autre, vous pouvez avoir des performances qui vont du simple au double, et il existe plethores de methodes pour optimiser un programmes, et plethore d'erreur pour qu'il rame. Moi j'attends simplement qu'on me "montre" comment ils ont réussi à tirer véritablement partie du multicoeur...

En ce qui concerne mon cas je suis resté au même nombre de cœur mais la fréquence et le nombre d'opérations par cycle de mon nouveau processeur sont plus importants que sur l'ancien. La où je voulais en venir c'est que c'est bien le processeur qui est limitant pour moi sur DCS et non la carte graphique.

C'est possible. Moi je remarque que les deux jouent, si on pousse trop les graphismes on perd en FPS, si on pousse trop le "scénique" on perd en FPS aussi...

Pourquoi je parlais de la physique de DCS, il y a pour moi deux situations possibles :
- soit DCS rame plus que les autres jeux car il fait plus de calculs (qui seraient du coup liés à la physique et au fait qu'il essaye de simuler plus de phénomènes réels que les autres);
- soit il ne fait rien de significativement plus impactant sur les performances que les autres jeux et en ce cas je me demande bien à quoi DCS utilise mon processeur.

Je ne pense pas que la physique soit particulièrement gourmande sur DCS... Je pense que ce qui différencie DCS de pas mal d'autres jeux, le nombre d'objets parfois très détaillés et une mauvaise gestion des LOD... par exemple, ce qu'il faut savoir, c'est que même si un objet prend 2 pixel sur l'écran, si l'objet en question fait 100 000 triangles, et ben les 100 000 triangles sont quand même dessiné (les uns sur les autres, mais dessinés quand même). C'est pour ça que je dis que ça peut être trompeur, quand on dit que le graphisme n'est pas le goulot d'étranglement... le cas typique c'est les particules, et c'est typiquement un problème d'optimisation: ils devraient prévoire un modèle simplifié quand on est "loin", pour pas que la carte graphique se tape 50000 particules à dessiner pour juste aboutir à une ligne blanche, c'est idiot. Ensuite les modèles de collision sont assez détaillés dans DCS, ça fait boulot, mine de rien, et finalement, ils ont peut-être un problème d'optimisation du scénique, comme j’expliquais plus haut: c'est à dire qu'ils font des calculs inutiles sur ce qui "ne bouge pas" (typiquement, une maison), mais ça m’étonnerait qu'ils soient gorets à ce point...

Je veux dire entre The Witcher III et DCS qu'est ce qui justifie que dans un cas le GPU est limitant (et le CPU est assez peu sollicité) et dans le second c'est le CPU ? Soit DCS fait plus soit il a une manière singulière de gérer les graphismes.

Non mais de toutes façon, soyons clairs: DCS utilise beaucoup plus massivement le CPU qu'un jeu comme The Witcher III, ça c'est une évidence, DCS est un jeu très gourmand en CPU, probablement plus que tout ce qui existe sur le marché... mais ça ne veux pas dire que DCS ne sait pas plomber la carte graphique pour autant... quand bien même the The Witcher III aurait l'air beaucoup plus impressionnant. Comme j'ai déjà dit, ça parrait pas, mais les modèles des avions dans DCS sont massifs en polygones ET en texture... A mon avis, il y'a 2 fois moins de polygones dans un avatar de The Witcher III que dans un des modèles d'avion détaillé de DCS... Moi quand je vois passer par exemple les screenshots du Mirage2000, je suis halluciné, parceque putain, ça, ça va faire cramer les cartes graphiques... les mecs qui font les modes se rendent pas trop compte on dirait, ils font leurs tests avec UN avion à l'écran, ça va, ça passe... mais t'en fout 5 ou 6 pareils, la carte graphique est à genoux, alors si en plus le LOD est mal géré, je vous dis pas les dégats.

Mais effectivement, par exemple si on prend ça, puisque tu évoquait The Witcher III http://wpc.4d7d.edgecastcdn.net/004D7D/ ... nymore.png C'est soigné, c'est joli, je dirais, c'est bien réalisé, mais effectivement, y'a pas TANT de polygones que ça quand on y regade de plus pres, et il y'a beaucoup plus de moyens d'optimiser, car le champ de vision est beaucoup plus restreint... ce qui est derrière la montagne est derrière la montagne, pas besoin de le calculer, et ce genre de jeu peuvent être optimisés assez facilement via des partitionnement d'espace, ce qu'on ne peut pas faire dans un jeu comme DCS, car la DCA qui a 500 km de là, doit être géré aussi surement que l'avion qui est 20 metre, on peut pas mettre en someil la DCA juste parcequ'elle est loin. Bon ils doivent bien optimiser un minimum hein, mais c'est pas aussi facile est brutal qu'un jeu comme The Witcher III, où on peut se permettre de gérer l'espace comme un damier. Et je devine même, que dans cette image: http://www.cinealliance.fr/wp-content/u ... 694491.jpg le décors au fond n'est qu'une image, une succession de plans texturés... peut-être remplacé le moment oportun par du vrai polygon... Bon, tout ça, ce sont des technique d'optimisation, de "tricherie" en quelque sorte, qu'on peut faire sur ce genre de jeu, mais sur DCS c'est pas possible.

PS: je ne comprends pas ton exemple sur la collision. C'est bien la preuve que de simuler de la physique c'est exigeant en terme de calculs ce qui était mon propos un peu plus haut ??

En fait, la détection de la collision, c'est pas vraiment ce que j'appelle de la physique. Ce que j'appelle de la physique, c'est de calcul les forces et les impulsions selon la masse, les propriétés physiques d'un objet, sa dynamique... Les collisions font générallement partie intégrante du moteur physique puisque oui, la plupart des dynamiques intéréssantes sont crée par des colisions (un cube qui rebondit par terre par exemple), mais en réalité, la détection de collision est surtout juste la base de n'importe quel jeu où tu tire sur des énemis et où tu te cogne contre les murs, quel que soit le réalisme du moteur physique... ce qui est massif à calculer, c'est pas la trajectoire de l'obus (qui est un calcul de physique, mais ça va vite, et pour résumer c'est: position += velocité += gravité * masse, c'est à dire en gros six additions et trois multiplcations et si vraiment t'as envie, t'ajoute un damping pour la trainée ), ce qui est lourd, c'est de tester et vérifier chaque obus, pour voir si il rentre effectivement ou non en collision avec X polygones d'un modèle de collision, c'est pas de la physique à proprement parlé, c'est du calcul de trigonométrie pour simplement tester "ça passe ? Oui / non", mais ça requière quelques bons calculs trigonométriques sur un nombre d’itération qui peut vite devenir délirant si les objets à tester sont complexes.

Et les modèles de simulation peuvent être très détaillés on en sait rien. J'ai travaillé avec des algorithmes qui prenaient 16*32 variables en entré (donc peanuts) et qui mettaient à genoux la machine sur laquelle je travaillais.

Du peu que j'ai testé à faire du moteur physique, on arrive assez facilement à un résultat impressionnant sans que ça soit très gourmand en calcul... DCS a fait certainement mieux que moi, moi ce que j'avais fait, c'était vraiment la base... trois tenseurs (trois matrices) et basta... mais, 3, 4, 5, même 8 matrices, c'est pas la mort... on peut avoir des trucs plus violents quand il faut se taper une animation "skelete" d'un avatar. Donc, évidemment, c'est pas transparent, mais je pense pas que ce soit ce qui plombe le plus, par contre, c'est long et chiant à élaborer si on veut faire un modèle de vol conforme à un prototype réel (un model qui a seulement l'air vrai, même plus vrai que les SFM de DCS, c'est facile), ça oui, mais c'est pas si gourmand que ça en calcul brut.

[falcon29]

C'est assez bizarre de comparer des jeux qui se vendent a des millions d'exemplaires avec DCS.
Le studio fait avec ces moyens je pense qu'il ne faut pas perde de vue qu'ils doivent rester rentable.

Mais je serais interesse de comparer le nombre de personne travaillant sur DCS et de le comparer a the witcher 3. De meme pour leur budget developpement et leur rentabilite.

Mon petit doigt me dit que c'est comparer un industriel avec un artisan.

[falcon29]

Il reste toujours le crowfunding si vous voulez les aider

[Bacab]

@sedenion j'entends bien tes arguments.

En revanche la où je voulais en venir sur la modélisation de la physique c'est que le nombre d'entrés ne conditionne pas la complexité des calculs et que la complexité dépends du résultat voulu. Si on prend un simple calcul de balistique il est possible d'ajouter des paramètres pour affiner les résultats. Ne serait-ce qu'ajouter les frottements, selon la façon dont ils sont modélisés, cela ajoute beaucoup de complexité à ton programme. Il y a quelques années c'était un de mes exercices en cours et sur un "simple" calcul en 2D de trajectoire on arrivait à des choses complexes et exigeantes en terme de calcul.

[white-sky]

@sedenion : justement tu prends l'exemplr d'une base au sol avec des appareis et c'est bien ce qui démontre le manque d'opti.

Tu considères que le niveau de détails reste le même or il y'a une série de LODS qui virent déjà pas mal de détails à 50m de distance (contrairement à ce que tu dis ), de sorte que la CG sera tout sauf dépassée (perso avec une 970 je fais tourner le jeu à 45 fps en max en 4k). Le jeu en lui même est donc f'autant plus étrange dans son opti que certaines configs pourtant haut de gamme vont ramer sans raison apparente. D'ailleurs pour info entre le 720p et le 4k je perds... 10 fps. Sur un jeu où la partie graphique est importante, (j'ai lu cryengine plus haut) je divise mes fps par 3 et je tourne à 30-40 fps SLI activé...

Donc non pour moi DCS est affreusement mal optimisé niveau CPU, il suffit de voir comment le jeu fige parfois pour une simple passe roquette, faudra être costaud pour me dire que les effets de particule de 2003 mettent à genou ma config...

[sedenion]

@sedenion
En revanche la où je voulais en venir sur la modélisation de la physique c'est que le nombre d'entrés ne conditionne pas la complexité des calculs et que la complexité dépends du résultat voulu. Si on prend un simple calcul de balistique il est possible d'ajouter des paramètres pour affiner les résultats. Ne serait-ce qu'ajouter les frottements, selon la façon dont ils sont modélisés, cela ajoute beaucoup de complexité à ton programme. Il y a quelques années c'était un de mes exercices en cours et sur un "simple" calcul en 2D de trajectoire on arrivait à des choses complexes et exigeantes en terme de calcul.

Oui, mais "ajouter" ce genre de détail comme tu dis, on le fait sur des logiciels d'ingénierie, comme CATIA par exemple, parce-qu’il y'a une vraie nécessité de simulation fine et vraiment le plus fidèle à la réalité pour le coup, et on se moque du temps de calcul, parcequ'on a des clusters de calculs dans le data-center pour le faire... Mais dans un jeu vidéo, aucun développeur ne serait assez fou pour implémenter ce genre de détail... et une aile d'avion se réduit à deux, peut-être trois ou quatre tenseurs plans, bêtement "plans" (sans courbe ni volume), parce-que, crois moi, ça suffit déjà largement pour donner un résultat très intéréssant. Donc oui, on peut faire très détaillé, mais c'est pas comme ça qu'on raisonne dans le jeu vidéo, et à mon avis, pas même chez ED. Ca n'empêche pas que ED a certainement fait quelque chose de très bien, de mieux que ce que tu trouve dans Flight Simulator (dont, il faut bien le reconnaître, les modèles de vol sont à chier). Au bout du bout, je pense que les AFM dans DCS sont bien réalisé, mais ne représentent vraiment qu'une petite partie des calculs... d'ailleurs, avez-vous réellement perçu une chute de FPS depuis l'introduction des AFM ? Moi ce que j'ai remarqué, c'est que ce qui fait chuter les FPS, c'est pas les AFM, c'est les tableau de bord très détaillés, et les avions très détaillés... (rien que virer le tableau de bord peut faire bondire les FPS de +10 ou +20 parfois, et c'est pas parce-qu’ils évitent de calculer les mouvements des trois aiguilles qui tournent... )

[sedenion]

@sedenion : justement tu prends l'exemplr d'une base au sol avec des appareis et c'est bien ce qui démontre le manque d'opti.

Tu considères que le niveau de détails reste le même or il y'a une série de LODS qui virent déjà pas mal de détails à 50m de distance (contrairement à ce que tu dis ), de sorte que la CG sera tout sauf dépassée (perso avec une 970 je fais tourner le jeu à 45 fps en max en 4k).

Non non, je ne dis pas qu'il reste le même, je dis qu'il est mal géré... nuance. Et il y'a d'ailleurs eu des discutions à ce sujet sur le forum ED, où certains utilisateurs ont farfouillé dans les fichiers de définition de LOD pour se rendre compte que certains modèles restaient détaillés jusqu'à l'infini.

Le jeu en lui même est donc f'autant plus étrange dans son opti que certaines configs pourtant haut de gamme vont ramer sans raison apparente. D'ailleurs pour info entre le 720p et le 4k je perds... 10 fps. Sur un jeu où la partie graphique est importante, (j'ai lu cryengine plus haut) je divise mes fps par 3 et je tourne à 30-40 fps SLI activé... Donc non pour moi DCS est affreusement mal optimisé niveau CPU, il suffit de voir comment le jeu fige parfois pour une simple passe roquette, faudra être costaud pour me dire que les effets de particule de 2003 mettent à genou ma config...

Mais là je te dirais: c'est peut-être justement pas les particules le problème (c'est peut-être ça hein, ils ont peut-être une fonction de rendu des particules complètement à chier) mais ça peut aussi être ce que j'ai expliqué avec la détection des collisions... c'est à dire que du moment qu'il y'a quelques projectiles et une ou plusieurs cibles regroupés à un même endroit, le moteur va devoir faire le test de collision : N roquettes * (N objets * N faces du collision model)... Donc sur un lapse de temps réduit, ben ça va ramer...

si non, à part ça, le changement de résolution est trompeur, c'est pas un bon test en fait... Ca fait certes perdre un peu en FPS de rendre sur une grosse image que sur une petite image, mais comme j'expliquais plus haut: quoi qu'il arrive, si la carte graphique doit se manger 300 000 polygones et 50 000 particules, que ce soit sur du 640*480 ou du 4k, elle va les manger quand-même, et calculer autant de sommets, de normales et de de composants de texture dans un cas comme dans l'autre. Donc oui, à "vide", une passe de rendu 3D prendra 4 fois moins de temps sur du 512*512 que sur du 2048*2048, c'est à dire que de 8000fps on va passer à 1000fps par exemple, mais dès qu'on ajoute de la vraie bouillie à dessiner, l'écart de FPS est minime, pourvu que les buffers de la carte graphiques soient adaptés, parceque c'est pas de "planter un pixel" sur une image qui lui prend du temps, mais de se farcir X interpolations de normales par exemple.

[overkillke2]

Vidéo en directe sur youtube!

[Exocet78]

Tiens je me suis fait ban du chat gratuitement hier


Si non ça a l'air fluide..

[tips]

Vidéo en directe sur youtube!

Désolé, pas de vidéo.