![Biggrin :biggrin:](./images/smilies/biggrin.gif)
++
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é).Bacab a écrit :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.phoenix a écrit :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.Bacab a écrit :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.
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 a écrit :@ 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.
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...phoenix a écrit :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.
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...Ghostrider a écrit :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
Je connais, c'est ce que j'utilise sur le serveur dédié à BoS.gilles41 a écrit :@ phoenix :
essai Bill2's process manager
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.sedenion a écrit :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...phoenix a écrit :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.
Les serveur dédié arrive pour 2053 normalementsedenion a écrit :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...Ghostrider a écrit :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
Hum, non, je suis très sceptique, et j'explique pourquoi:Bacab a écrit :@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.
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).Bacab a écrit :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é.
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...Bacab a écrit :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...
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...phoenix a écrit :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.
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...Bacab a écrit :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.
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...Bacab a écrit :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.
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...Bacab a écrit :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.
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.Bacab a écrit :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.
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.Bacab a écrit :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 ??
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.Bacab a écrit :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.
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... )Bacab a écrit :@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.
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.white-sky a écrit :@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).
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...white-sky a écrit :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...
Désolé, pas de vidéo.overkillke2 a écrit :Vidéo en directe sur youtube!