Supreme Commander 1 & Forged Alliance

[Niklaos]

Sachant que les parties classées sont à 500 unités et schant qu'on peux pas dépasser 1000 unités par camp dans les parties standards jouées par presque tout les joueurs sur le GPGnet, ça sert à quoi vos tests?

Ben a rien il sont dans leur tripe a 5000 unites par camp j'ai du mal a comprendre !

[Kahn Lusth]

Il est tout à fait possible de jouer avec plus de 1000 unités par joueur en multi non classé. Il suffit que l'hébergeur active le mod qui va bien. ET tous les joueurs (je dis bien tous) profitent de cette limite.

Ahhhh c'est génial ça le coup du mec qui active le mod et que tout le monde en profite!
Par contre quand je vois des parties où les mecs se mettent à ramer comme des malades à peine ils dépassent la centaine d'unités, m'est avis que ce genre de délires ne sera valable que d'ici un ou deux ans.

[Slayertom]

Ben a rien il sont dans leur tripe a 5000 unites par camp j'ai du mal a comprendre !

Bien perso je me suis fait un petit game contre un cpu avec la limite d'unite a 10 000 unites et avec le X2 en ressource et en moins d'1 heures j'avais dans les 5000 unites (ca compte aussi les batiment et c'etait majoritairement des T1). C'etait plutot infernal a gerer principalement parce que les unites etaient extrement longues a repondre aux ordres (parfois 5 Mins avant qu'elles commencent a bouger pour se metre en formation), pourtant j'etait a 20 fps, il doit y avoir un soucis avec le jeux ou le mod, l'ia enemi ne faisait plus rien passé les 40 premiers minutes (mais bon faut dire qu'au debut je l'ai entouré de tourelles pour pas qu'elle vienne m'enmerder).

Apres cette petite experience, je me dit que c'etait vraiment du foutage de gueule lorsqu'ils annoncaient un supreme commander avec 50 000 unites ! (option disponible dans la premiere version de la beta !)

[Niklaos]

Apres cette petite experience, je me dit que c'etait vraiment du foutage de gueule lorsqu'ils annoncaient un supreme commander avec 50 000 unites ! (option disponible dans la premiere version de la beta !)

Bon mais aucun PC peut le faire pour le moment mais dans 5 ans avec les patchs et les addon ca pourra être fait !

La charge du proc est exponentiel au nombre d'unités sur la carte donc c'est normal que tu rame (surtout que ton proc est pas un foudre non ?)

[Kahn Lusth]

Apres cette petite experience, je me dit que c'etait vraiment du foutage de gueule lorsqu'ils annoncaient un supreme commander avec 50 000 unites ! (option disponible dans la premiere version de la beta !)

Pour gerer ça en tant qu'humain là il faut carrément se faire greffer deux ou trois quad core dans le cerveau si on veuxpas oublier constament la moitié des unités paumées au milieu d'une marée d'icones.

[Slayertom]

Pour gerer ça en tant qu'humain là il faut carrément se faire greffer deux ou trois quad core dans le cerveau si on veuxpas oublier constament la moitié des unités paumées au milieu d'une marée d'icones.

Bien la gestion etait pas trop dificile, une centaine de suport commander qui construisent les ressrouces, 200 ingenieurs lvl 3 qui assistent les 50 factory et les unites qui sortent a la chaine et s'empile dans un coin de la carte. Vu que l'IA a s'etait endormis ("It s oh so quiet") et ne reagissait plus, pas besoin de gerer des combats, c'etait une sorte de sim city plus qu'autre chose.

[--Lourd--]

Oula le E6600 c'est quand même un petit monstre, même à sa fréquence d'origine, donc oc à 3700mhz je vous laisse imaginer

[Niklaos]

Oula le E6600 c'est quand même un petit monstre, même à sa fréquence d'origine, donc oc à 3700mhz je vous laisse imaginer

Un quad c'est deux E6600 donc deux fois mieux

[Slayertom]

Bon je me suis refait un game, ce coup si j'ai diversifié un peu plus les unites, resultat j'en avais que 4000 au bout de 1heure 30. Le jeux est resté fluide jusqu a la fin et ce coup ci j'ai verfiie le nombre de fps avec teamspeak overly (oscille entre 4 fps et 20 fps suivant le zoom) et la charge des processeurs (effictivement je reste bloque a 70 % et je ne l'ai pas vu depassé, mais comme je fait alt tab pour le mater peut etre que ca decharge de 30% le pross le temp que je le lise). J'ai aussi eu le bug tres flagrant du jeux qui n'arrive plus a gerer les odres par contre ce coup ci l'ia enemis etait moins endormis (alors que c'etait un niveau de dificulté plus faible)

Plutot que des beaux discours je vous propose le replay ainsi que quelques images:

[Daystrom]

Au passage la partie en 4vs4 entre possesseur de Multicore on ce la fait quand ?
Moi je propose jeudi ou vendredi soir.

[Slayertom]

Au passage la partie en 4vs4 entre possesseur de Multicore on ce la fait quand ?
Moi je propose jeudi ou vendredi soir.

Vendredi soir je peux pas, c'est poker time. Jeudi soir ok par contre.

[Niklaos]

Attendez que Oor-tael et moi on ai nos multis cores on vas vous faire une petite demo de ce que l'on sait faire.

Le plus drole je pense que c'est de faire un 2 vs 2 vs 2 vs 2 (en gros 4 teams de 2) c'est ultra sport et fun a mon avis
Sur une carte 40km ca t'explique le mot "stratégie" ce genre de parties.

[Daystrom]

La partie que je propose est surtout la pour verifier que les deco que connait Slayertom sont du à des monocore.
Au passage tu pense l'avoir quand ton nouveau PC.

[Slayertom]

La partie que je propose est surtout la pour verifier que les deco que connait Slayertom sont du à des monocore.
Au passage tu pense l'avoir quand ton nouveau PC.

Bien j'ai deja ma reponse, j'ai fait un 4vs4 niquel dimanche avec saya (regardez mes precedants commentaires) et dans le ren_shownetworkstats il n'y avais personne en negatif meme au moment le plus fort de la partie et en me servant de ma config comme reference, tout le monde avait au minimum un dual core.

[Tiax]

J'ai un dual core, je me joins volontiers à vous pour la partie

[HellBoy]

+1 reglez ca en MP svp

Et arrettez de parler d'octo parlez de Bi-quad putain ca existe pas encore les Octo et je vois pas comment ca pourait exister avant un an !!!

D'ailleur je vois pas comment un bi-quad peut faire la dif comparé a un quad seul vu que le code du jeu est fait pour fonctionner sur 3 cores + 1 pour l'os.

Justement l'explication de Neutrino est simpliste. Il y a bien plus que 4 threads, et donc rien n'empêche le jeu de dispatcher ses threads sur 8 cores. Est-ce que çà présente un intérêt j'en sais rien.
Je veux bien croire daystrom quand il dit que la charge s'équilibre sur les 8 cores .... sur un quad, quand on modifie l'affinité de supcom pour qu'il n'utilise plus que 2 cores et qu'on le repasse à 4 cores, la charge s'équilibre sur les 4 cores et n'est plus du tout répartie comme l'a expliqué neutrino. il semble bien qu'une répartition soit forcée au démarrage du jeu sans doute pour conserver certains types de threads sur le même core. Mais il n'empêche qu'on peut manuellement déstabiliser cette répartition. Et donc l'utilisation de 8 cores ne me surprend en rien. Simplement je connais l'animal Daystrom et il est foutu d'affirmer tout et son contraire en deux temps trois mouvements alors si on doit aborder le sujet des perfs çà serait cool que ce soit fait avec entendement et preuves à l'appui c'est tout. Donc merci à Slayerstorm pour son premier replay.

[SpydZ]

Au passage la partie en 4vs4 entre possesseur de Multicore on ce la fait quand ?
Moi je propose jeudi ou vendredi soir.

+1 pour le 4vs4, j ai pas rejoué depuis la beta faute de temps ( guild wars quand tu nous tiens :P ),mais il dois me rester quelques restes ...
pour info j ai un opteron 165 a 2,4Ghz.

[Niklaos]

On l'ouvre comment la console dans SupCom ?

[Slayertom]

On l'ouvre comment la console dans SupCom ?

Je me rappel jamais si c'est ù ou * alors j'appuye sur les 2 jusqu'a ce qu'elle s'affiche.

[HellBoy]

Ton replay est intéressant car il permet de mettre en évidence froidement à quel point supcom est gpu limited, surement pas cpu limited (désolé d'enfoncer cette croyance originelle, ce qui ne veut pas dire que supcom n'est pas gourmand en cpu), toujours potentiellement FSB limited mais pas démontré. Je ne suis pas allé complètement au bout de ton replay. Je dirais nénamoins que la charge a pu grimper jusqu'à 55% et que par période elle redensecendait considérablement à 30% sans impacte sur la fluidité. Ce qui est certain c'est l'aspect GPU limited, car même si j'ai maintenu du 30FPS de manière assez constante (en 1920*1200 tout à fond sauf AA) il m'était possible de faire chuter les FPS à 5 . En zoom out très reculé, sans avoir atteint le niveau icone stratégique la framerate chute, jusqu'à remonter rapidement à 30FPS dès qu'on arrive au niveau icones stratégiques, idem en zoom in , plus on se rapproche, et je ne parle même pas des angles de caméra qui éclatent tout. Le passage à 1024*768 est détails tout mini permet de grimper à 40FPS mais on peut avoir des chutes de FPS majeures lorsque l'on se place en situation de charge de rendering importante (niveau de zoom intermédiaire avec une chiée d'unités en mouvement).

Difficile de caractériser l'influence de la FSB dans la mesure où la lourdeur du rendering vient automatiquement ralentir la cpu puisque le gpu ne suit plus (cf hardware.fr qui explique très bien ce problème). La geométrie semble être le véritable point noir de supcom où autant de polygones en déplacement constituent sans doute le véritable goulot d'étranglement ......

J'ai par contre remarqué au bout d'un certain temps le phénomène "rallongement du temps". FSB ? imperfection du code ?

[Slayertom]

Bien a mon avis le probleme de rallongement du temp viens plus du jeux que du pross. On le vois dans mon replay, le jeux pedale dans la choucroute et n'arrive plus a gerer tous les parametres.

Car je sais pas si on le vois sur le replay mais parfois, je donnais des ordres et ils se declanchaient 5 ou 10 minutes apres quand il ne refuse carement pas de s'executer (c'est flagrant a la fin ou je demane a mon armée de terre, environ 1000 unites, de se deplacer dans la base du cpu et ou seulement 50 unites bougent). Et pourant en mattant les processus, la charge du processeur est correct (j'avais meme bittorent qui bossait a coté) et le jeux ne rame pas (ou presque pas, l'interface reagit, le zoom est rapide, l'acces au menu d'option ou le alt tab repond immediatement).
Le plus etrange est que certains ordres ne repondent plus (construction ou deplacement) alors que d'autres continuent de marcher (attaque aerienne, support de factory, defense anti aeriene, etc).

Donc je me demande si c'est le mod ou sup comm qui est pas au point pour la gestion d'un grands nombres d'unités (la on parle de pret de 3000 unites et 1000 batiments).

[Niklaos]

Justement l'explication de Neutrino est simpliste. Il y a bien plus que 4 threads, et donc rien n'empêche le jeu de dispatcher ses threads sur 8 cores. Est-ce que çà présente un intérêt j'en sais rien.
Je veux bien croire daystrom quand il dit que la charge s'équilibre sur les 8 cores .... sur un quad, quand on modifie l'affinité de supcom pour qu'il n'utilise plus que 2 cores et qu'on le repasse à 4 cores, la charge s'équilibre sur les 4 cores et n'est plus du tout répartie comme l'a expliqué neutrino. il semble bien qu'une répartition soit forcée au démarrage du jeu sans doute pour conserver certains types de threads sur le même core. Mais il n'empêche qu'on peut manuellement déstabiliser cette répartition. Et donc l'utilisation de 8 cores ne me surprend en rien. Simplement je connais l'animal Daystrom et il est foutu d'affirmer tout et son contraire en deux temps trois mouvements alors si on doit aborder le sujet des perfs çà serait cool que ce soit fait avec entendement et preuves à l'appui c'est tout. Donc merci à Slayerstorm pour son premier replay.

Ben d'aprés les tests de Hardware.fr l'interret de dispatcher les threads sur plus de 4 cores est presque nul. Pour dire vrais si mes souvennirs sont bons je crois meme que l'interret est de 3 cores pour le jeu seul le 4éme core etant utilisé pour Windows et les applications en tache de fond !
Donc bon tu peux equilibrer 8 caculettes Windows sur 8 cores mais l'interret est nul je pense que c'est la meme histoire avec les threads de SupCom. Même a plusieurs trheads sur un core le core ne saturera pas ! L'interret du Bi-Quad est donc a mes yeux nuls a part pour tuer le compte en banque ... aprés chacun est libre de faire ce qu'il veut si il en a les moyens.

Edit : et si je ne m'abuse le thread principale vas de toute facon finir par saturer un core les autres threads même dispatchés ne pouront donc pas aller plus vite que le principale et limiteront leur vitesse en fonction de ce dernier.

[Niklaos]

Ton replay est intéressant car il permet de mettre en évidence froidement à quel point supcom est gpu limited, surement pas cpu limited (désolé d'enfoncer cette croyance originelle, ce qui ne veut pas dire que supcom n'est pas gourmand en cpu), toujours potentiellement FSB limited mais pas démontré. Je ne suis pas allé complètement au bout de ton replay. Je dirais nénamoins que la charge a pu grimper jusqu'à 55% et que par période elle redensecendait considérablement à 30% sans impacte sur la fluidité. Ce qui est certain c'est l'aspect GPU limited, car même si j'ai maintenu du 30FPS de manière assez constante (en 1920*1200 tout à fond sauf AA) il m'était possible de faire chuter les FPS à 5 . En zoom out très reculé, sans avoir atteint le niveau icone stratégique la framerate chute, jusqu'à remonter rapidement à 30FPS dès qu'on arrive au niveau icones stratégiques, idem en zoom in , plus on se rapproche, et je ne parle même pas des angles de caméra qui éclatent tout. Le passage à 1024*768 est détails tout mini permet de grimper à 40FPS mais on peut avoir des chutes de FPS majeures lorsque l'on se place en situation de charge de rendering importante (niveau de zoom intermédiaire avec une chiée d'unités en mouvement).

Difficile de caractériser l'influence de la FSB dans la mesure où la lourdeur du rendering vient automatiquement ralentir la cpu puisque le gpu ne suit plus (cf hardware.fr qui explique très bien ce problème). La geométrie semble être le véritable point noir de supcom où autant de polygones en déplacement constituent sans doute le véritable goulot d'étranglement ......

J'ai par contre remarqué au bout d'un certain temps le phénomène "rallongement du temps". FSB ? imperfection du code ?

Juste comme ça, je continue de soutenir mon idée disant que ce jeu est plus facilement CPU limited que GPU. Tu parle du fameux phénomène de "rallongement du temps". Quand le temps commence a s'écouler moins vite c'est que le CPU est limited il ralentit donc le temps et passe plus de temps a avoir les nouvelles adresse des unités et autres projectiles. La carte 3D affiche elle en temps réel ce que lui donne le proc dans ce cas c'est donc un CPU limited. Le jeu restant fluide sur le plan visuel !
Pour le multi il suffit qu'un seul CPU soit limited pour foutre la merde les autres devant se synchronisés sur lui (souci très visible dans les parties a 8 :P).

Maintenant si tu rame visuellement c'est que le GPU a trop de polygones et de textures a rendre (ce qui doit être dure vu que 180 Loyalistes en mouvement n'ont pas réussis a faire tomber ma 6600GT a moins de 10fps). Je n'ai donc pas trop rencontrés cette situation de perte de FrameRate sauf quand il y a beaucoup d'effets complexes genre Fumée et/ou boucliers. Et dans cette situation je ne crois pas que le temps ralentisse mais plutôt que le jeu saccade.
Pour résoudre ce souci il "suffit" de rajouter du GigaFlop sur la partie graphique du PC donc par exemple rajouter une deuxième CG en SLI.

Le ralentissement temporelle du jeu étant fréquent mais souvent très faible (utilisez un chrono vous allez voir y'a souvent 5secondes par minutes) la saccade est elle rare.
Donc je reste bien dans l'idée que c'est bien CPU qui et en genoux le premier même si cela est parfaitement géré par le moteur du jeu qui a visiblement prévu que ça allait souvent arriver.

NB : ce sont mes obs perso que j'ai déduit de ce que j'ai lu et de ce que je sais je ne dis pas que ce que je dis est parole d'évangile mais dans ma logique et c'est comme ça je vois les choses :P

PS : Quand vous donnez les charges en % ca sert a rien de donner une charge pour 2, 4 ou 8 core faut donner la charge pour chaque core !
un 100% et 3 0% sortiront comme un quand a 25% ce qui con

[Slayertom]

Quand on parle de charge pross pour des dual or quad core, on fait la moyenne, vu que la charge de toute facon se divise de façon equitable sur chaque core.

[MetalDestroyer]

Moi je dis tout simplement que SupComm ne tire pas encore partie du multicore de facon optimal :P Discussion close

[Niklaos]

Moi je dis tout simplement que SupComm ne tire pas encore partie du multicore de facon optimal :P Discussion close

Non mais il en tire partie et c'est deja fantastique :P

[Slayertom]

Mais non c'est nul de faire ca ...

ce qui est utile c'est ca :


Avec ce genre de graph on voit bien qu'il y a un bien un threads principale quand le core chargé du tread principale arrive a 100% le jeu rame et les autres threads attendent le principale. Alors qu'un Bi quand ne sera qu'a 20% donc je suis désolé donner un moyenne pour un proc multi core c'est aussi stupide que dire tout les francais vont acheter une baguette tout les matins
Non mais il en tire partie et c'est deja fantastique :P

Pas plus stupide que de parler en theorie des performance dual core quand on a encore un monocore

Je dit pas ca mechament hein mais je prete plus d'attention a l'avis de hellboy ou de daystorm quand ils parlent de quad core que des infos que tu a lu quelque part et qui sont sujet a caution (meme si j'aime bien hardeware fr).

[HellBoy]

Juste comme ça, je continue de soutenir mon idée disant que ce jeu est plus facilement CPU limited que GPU. Tu parle du fameux phénomène de "rallongement du temps". Quand le temps commence a s'écouler moins vite c'est que le CPU est limited il ralentit donc le temps et passe plus de temps a avoir les nouvelles adresse des unités et autres projectiles. La carte 3D affiche elle en temps réel ce que lui donne le proc dans ce cas c'est donc un CPU limited. Le jeu restant fluide sur le plan visuel !

Alors je vais tâcher d'éclairer encore plus ta lanterne Je veux bien que ce soit cpu limited, le seul soucis c'est que dans ce cas très précis mon quad@3Ghz n'est qu'à 30% d'utilisation globale et surtout, le premier core n'est jamais à 100% contrairement à ce que laisse entendre neutrino. En tous les cas, sur des core 2 duo cadencés à plus de 3ghz tu n'atteins jamais 100% ou alors sous forme de pics mais assez peu fréquents.

Donc le cpu limited : Non çà tient pas la route et c'est basé sur l'observation temps réel puisque mon clavier G15 me fournit cette information en permanence sur son écran LCD (pas besoin d'activer un 2ème écran ni de faire du ALT/TA. le ralentissement du temps n'est pas lié au cpu limited, il est lié à un autre goulot d'étranglement qu'on ne voit pas apparaître de manière manifeste (FSB ? algorithmes de temporisation qui sont déclanchés de plus en plus souvent suite à des problème d'interblocage dans le cadre de la gestion du pathfinding ?)
Par ailleurs tu comprends de travers l'article publié par hardware.fr : Ils ont noté simplement qu'avoir un 4ème core n'apportait pas de gain de perf supplémentaire. çà n'a strictement rien à voir avec la capacité ou non d'exploiter plus de 3 cores. Il faut distinguer le fait d'être capable de paralléliser sur plus de 3 cores du gain à utiliser plus de 3 cores. ce sont 2 choses différentes et qui prennent tout leur sens si tu considère qu'un autre élément de la machine peut jouer le rôle de goulot d'étrnaglement.

Très clairement : Supcom sait exploiter 4 coeurs, et d'après les observation de Daystrom, 8 également. c'est fichtrement intéressant. çà veut dire que si on parvient à identifier le goulot d'étranglement qui empêche de dépasser la charge globale de 30% sur on bi-quad xeon, de 55% sur un quad (sachant que dans chacun de ces cas aucun core n'est à 100% donc EXIT le facteur CPU limited) alors supcom peut réellement à l'avenir profiter d'un surplus de puissance cpu qu'il ne parvient pas (pour d'obscures raisons) à exploiter aujourd'hui et laisse entrevoir une possibilité de batailles encore plus gigantesques.

Si j'insiste tant sur le fait que Daystrom nous fournisse un replay c'est que visiblement il semble parvenir facilement à obtenir cette charge, alors que perso je n'y arrive pas. 1) parce que je suis moin bon que lui et que probablement il parvient à mieux contenir les attaques de l'IA 2) Peut être a-t-il trouvé un modèle de partie facilitant la création des conditions d'augmentation de charge. Mais encore une fois qu'il nous explique comment il s'y prend de manière détaillé pour qu'on puisse le reproduire, ou qu'il nous fournisse un replay, parce que de mon côté toutes mes tentatives ne m'oint jamais permis de me retrouver sur un niveau de charge pareil. et comme c'est pas la première fois que Day me dit qu'il arrive à ce genre de résultat, bah je me dit qu'il lui est relativement facile d'obtenir un replay. Mais bon, visiblement c'est l'omerta sur ce sujet.

Si la conf Bi-xeon de Day profite bien de la bande passante mémoire ou de tout autre chose je serais ravi pour lui. et je saurai quelle conf est nécessaire. Il faut savoir que Neutrino m'a quand même soutenu que le jeu tirait mieux partie du quad core que du bi-xeon dual .... j'ai quand même de gros doute. Day tiens le moyen de prouver par a+b que la FSB est peut-être importante, alors encore un fois j'attends son replay dès qu'il en aura un de potable.

[HellBoy]

Bien a mon avis le probleme de rallongement du temp viens plus du jeux que du pross. On le vois dans mon replay, le jeux pedale dans la choucroute et n'arrive plus a gerer tous les parametres.

Car je sais pas si on le vois sur le replay mais parfois, je donnais des ordres et ils se declanchaient 5 ou 10 minutes apres quand il ne refuse carement pas de s'executer (c'est flagrant a la fin ou je demane a mon armée de terre, environ 1000 unites, de se deplacer dans la base du cpu et ou seulement 50 unites bougent). Et pourant en mattant les processus, la charge du processeur est correct (j'avais meme bittorent qui bossait a coté) et le jeux ne rame pas (ou presque pas, l'interface reagit, le zoom est rapide, l'acces au menu d'option ou le alt tab repond immediatement).
Le plus etrange est que certains ordres ne repondent plus (construction ou deplacement) alors que d'autres continuent de marcher (attaque aerienne, support de factory, defense anti aeriene, etc).

Donc je me demande si c'est le mod ou sup comm qui est pas au point pour la gestion d'un grands nombres d'unités (la on parle de pret de 3000 unites et 1000 batiments).

Ton observation est extrêment pertinente, et je vais apporter quelques éléments de réflexion que je tiens de ma connaissance en analyse de problèmes de performance sous Oracle. Et tu vas voir que çà peut être adapté à supcom pour comprendre ce qui peut se passer et que le cpu n'est pas forcément en cause :

Le temps de réponse d'un processus est le cumul du temps cpu consommé et du temps d'attente sur différentes ressources externes utilisées. il y a des ressources physiques (I/O disques, I/O réseau, I/O de tout type) et des ressources logiques. Les ressources logiques sont des structure définies au sein même du logiciel afin de pouvoir gérer des problèmes d'accès concurrent à d'autres structures logiques. Un exemple : Oracle gère l'accès concurrent aux données : il possède des mécanismes permettant déviter la mise à jour de la même donnée par deux processus simultanés. Pour çà Oracle utilise une ressources interne appelée "Enqueue". Si l'enqueue est détenue par un processus, alors le second va se mettre en file d'attente sans pour autant consommer de cpu.

Supposons que ce même genre de mécanisme existe dans la gestion du path finding : 2 unités doivent se déplacer mais risquent à un moment t d'occuper le même emplacement : Une des unités va devoir attendre. Supposons maintenant que l'unité A soit placée sur l'emplacement n°1 et doivent se déplacer sur l'emplacement n°2. Malheur, l'unité B est déjà localisée sur l'emplacement n°2, elle empêche donc l'unité A de se déplacer sur l'emplacement n°2. Or il se trouve que l'unité B veut se déplacer sur l'emplacement n°1, lui même occupé par l'Unité A qui ne peut le quitter tant de B n'aura pas quitté son emplacement .....

Indémerdable et pourtant pas consommateur de cpu car dans ces situations les tentatives d'accéder à la ressource ne se produise que lorsqu'un processus recoit un signal lui indiquant de rééssayer(En interne ce sont des sémaphores qui sont utilisées, un système de feu bicolore).

Dans ces cas de figure que l'on appelle "DeadLock" il faut un processus supplémentaire qui scrute l'apparition de ces interblocages afin de les débloquer et de trancher sur qui passera en premier. Pour éviter un excès de consommation cpu, ce processus ne tourne jamais de manière permanente. Il check fréquemment mais pas de manière continue. Si le pathfindind est mal géré alors on peut facilement imaginer que le nombre d'unités augmentant, ces situations risques de croitre de plus en plus sans forcément augmenter la charge cpu, mais vont provoquer un alongement du temps puisque ces attentes ne seront pas comptabilisée, mais constituerons pour autant du temps réel écoulé. Du point de vue du jeu il se sera donc écoulé moins de temps que réellement !

Si vous avez bien suivi les évolutions de la beta vous aurez pu constater que gpg a apporté de la souplesse aux unités T4 en leur permettant de traverser royalement les petites structures, de passer au travers des petites unités ..... quand la facilité l'emporte sur la résolution d'un problème complexe ......

[MetalDestroyer]

Muhahaha, je me croirais sur les forums de geekzone (anciennement cafzone) dans la section Segmentation Fault >_<