La 1.1 : Unity 5, 64bits...

[Dakitess]

J'y pense, je suis très sceptique concernant l'amélioration significative des perfs grace à cet MaJ dans la mesure ou un seul core restera accessible à la physique d'un seul vaisseau. Certes il y a des utilisations à plusieurs vaisseaux dans le voisinage, mais quand même pas des masses.

Sauf... Sauf... Le multijoueur ! Je n'y pensais pas, mais là pour le coup on se retrouve avec plein de vaisseaux, pour un montant de parts ingérables, à moins que les cœurs se partagent la tâche ! Ca a toujours été lé truc qui m'agaçait le plus par rapport aux perspectives de multi, les perfs. Mais si on peut voler à 4-5 avions de 100 parts chacun (déjà beaucoup ^^) ben c'est déjà pas mal ! Parce qu'aujourdhui, un total de 500 parts sur un cœur, on sait ce que ça donne... 2FPS.

[Nemecle]

Mec avec le multithreading si ils chient pas dans la colle tu pourras faire des vaisseaux de 800 parts sans broncher sur un laptop

[Dakitess]

Ou pas... Je comprends pas que tout le monde loupe l'état actuel de la chose, je ne suis quasiment rien de l'actu KSP, mais ça, je le sais xD :

Il n'y aura très vraisemblablement qu'un seul core disponible par vaisseau, du aux limitations du moteur physique / structure du code. Si bien que si on pourra faire cohabiter 4 vaisseaux de 200 parts à quelques mètres les uns des autres, il sera tout à fait impossible de les docker. Enfin si, le premier à 50FPS, puis paf docking, 400 parts pour l'un des bordel, 15FPS grand max. Puis docking avec l'un des autres bidules à 200 parts : KSP has crashed. Ou 2FPS pour docker le dernier et définitivement passer en slideshow.

C'est genre... Presque de notoriété publique X)

Y'a eu une erreur de formulation de Max dernièrement qui a relancé un peu l'espoir via ce thread :

http://forum.kerbalspaceprogram.com/thr ... ngle-Ships

Mais comme dit Marjorirm un peu plus bas :

"I have already heard them, and many many others say that it simply cannot be done. In fact if Squad had cracked it (they haven't) they would be screaming it from the rooftops"

Clair que si la piste existant seulement en projet sans rien de concret, SQUAD aurait laché quelque chose X) En l'état, ils ont même assuré rien ne permettrait de jouer avec un bordel de 600 parts sans des perfs similaires à l'actuelle version : pas glop xD

[x335]

Il n'y aura très vraisemblablement qu'un seul core disponible par vaisseau, du aux limitations du moteur physique / structure du code.

Mais... mais c'est complètement débile ! En fait ça ne changera absolument rien SAUF (et c'est tant mieux) le multi ! Donc en fait cette "avancée" sera inutile jusqu'à la sortie du multi... j'espère que ce sera la prochaine priorité...

[Dakitess]

Y'aura quand même sans doute un petit gain par core, ou le déchargement de quelques petites choses comme les effets d'échauffements, j'en sais trop rien... Mais ouais, la tendance actuelle est à dire que, comme suspecté, le framerate ne connaitra aucun réel bond en avant. M'enfin toute amélioration est bonne à prendre et j'ai déjà conçu des petites choses capables de tirer partie de cette gestion multithread xD

[Akinatronic]

Et bien l'un des avantages sera le 64 bits qui nous permettra de "casser" la limite des 3,4 go de RAM, et ça c'est déjà un bond en avant car on pourrait installer beaucoup plus de mods sans crashs réguliers, et au niveau FPS... On verra bien

[Nemecle]

Bon, je me suis fait quelques réflexions.
Dans les dernières devnotes, Squad a évoqué la façon dont certains éléments ont été réimplémentés pour Unity 5. Ou plus exactement, recodés : en effet, ils évoquent entre autres la mise en application de nouvelles bibliothèques, notamment pour les roues et l'affichage des orbites. Couplé à l'annonce du portage sur la peu puissante Wii U, il faut se faire une raison : Kerbal Space Program a bien été en partie reprogrammé. D'ailleurs en y réfléchissant, KSP ne devrait pas être aussi gourmand : point de vue graphisme c'est pas le Pérou, et niveau physique c'est pas 1000 objets, aussi finement soient-ils calculés qui devrait mettre à plat nos ordinateurs actuels. Le gros du travail du moteur réside en fait sur la précision : placer à quelques centimètres près un objet dans un espace de Milliards de kilomètres : mais ce ne sont pas des grands nombres qui effraient nos processeurs.
Bref, je crois sincèrement que KSP va bel et bien faire un bon de performance monstrueux dans les mises à jour à venir, n'en déplaise aux sceptiques
Et du coup me vient en tête une question pour vous : si tel est le cas, est ce que vous remplieriez votre jeu de nouvelles parts ou de Mods graphiques ?

[Dakitess]

Les mods graphiques sollicitent presque intégralement nos CG qui sont de toutes façons hyper sous exploités donc pas de grands changements à prévoir je pense ^^ Pour les mods de parts, pareil, leur variété n'affecte principalement que la mémoire et pas vraiment le CPU même si c'est vrai que plus de parts peut donner envie de faire des créations plus importantes à et plus chargées.

Sinon... Je demeure sceptique ouais c'est SQUAD ils pourraient pas s'empêcher de jazzer à tout ça s'il y avait un début d'espoir d'optimisation significative xD

Mais je n'espère que ça !!

[Skalou]

Je suis sceptique aussi sur le gain de performance CPU (mutithread etc...)

Mais je serais déjà content que le portage sur unity 5 n’apportent pas plus de bug que actuellement!

Si le 64 bits tiens la route et ben c'est top mais je vois ça comme un plus,
et oui je métrai carrément plus de mod à part et de truc qui consomment de la RAM que maintenant (nuages et co.)!
là j’opère une stricte sélection pour pas être embêter avec la RAM ( et j'aime bien les parts stocks avec l'arbre techno stock aussi).

Le mutithreading sera une avancé très importante mais je me dis "chaque chose en son temps", et de ce que j'ai compris c'est pas magique, pour être pris en compte c'est à Squad de réécrire une partie du code du jeu également, ce qu'ils n'ont pas fait pour le moment.

[oliezekat]

Si l'architecture de KSP ne s'appuie pas déjà sur un ordonnanceur, il est certain que l'implémentation du mutithreading va s'accompagner de nombreux bugs tant que tout le code n'aura pas été révisé. Car l'ordonnanceur est un élément capital pour dispatcher les processus à plusieurs threads, et leur allouer un ou plusieurs cores, en optimisant les choix selon les besoins ET des estimations pour que la charge soit régulée dans le temps. Il suffit qu'un gros processus soit toujours exécuté à l'arrache sans passer par l'ordonnanceur pour que celui-ci ne puisse pas faire une estimation correcte de la situation et que le bousin sature.
Nb: je bricole depuis 2 ans un ordonnanceur en Javascript (qui est monothread), la construction d'une app a rien à voir avec ce qui se fait, et les gains espérés sont obtenus si on ré-écrit tout. Entretemps, on a plein de bug à cause des processus non-ordonnancés.