(MAJ) sortie de clodo + Screenshots de BoB in-game !
#3801
Sur le multicore...
http://simhq.com/forum/ubbthreads.php/t ... ost3249155
... pas bon.
Comment en effet faire durer une simulation basée sur une technologie dépassée ou un pis-aller (ce machin "hybride") ? Désolé, mais en 2011, un jeu doit être en 64 bits et compatible multicores !
http://simhq.com/forum/ubbthreads.php/t ... ost3249155
... pas bon.
Comment en effet faire durer une simulation basée sur une technologie dépassée ou un pis-aller (ce machin "hybride") ? Désolé, mais en 2011, un jeu doit être en 64 bits et compatible multicores !
#3802
un jeu pas forcement, mais une simu, oui. c'est inconcevable que sa ne soit pasChrisDNT a écrit : Désolé, mais en 2011, un jeu doit être en 64 bits et compatible multicores !
multi-core, d'ailleurs je ne le conçois pas... a voir si dans leur ini ils ont bien mit le multi-core, ou si ils ont tellement reduit les settings qu'un seul core suffisait....
dans 1946 la gestion multicore existais deja...
#3803
GOURMAND, non dans IL2 1946 la gestion multicore n'xistait pas.
change le processaffinitymask= dans IL2 1946 et dis moi si tu gagne 1 seul fps en plus.
ca a déja été testé des dizaines de fois et ca ne change absolument rien.
Luthier a par contre répondu pour IL2 COD et a proposé aux simmers de tester IL2COD en mettant le processaffinitymask=1 pour le faire tourner sur un seul core afin de voir la difference.
je n'ai pas eut le temps d'essayer, mais je le ferais afin de voir.
par contre j'avais deja vérifié l'occupation cpu dans le gestionnaire de taches et m'etait etonné de voir que cette occupation cpu variait entre 19% et 45%. ce qui est effectivement faible comparé par exemple a ROF qui lui est tres bien multitreadé. et occupe entre 65 et 85% de mon cpu.
je suis donc d'avis qu'IL2 COD est bien multithreadé, mais pas suffisamment.
ou alors que le thread principal est trop gourmand par rapport aux autres. ce qui fiat qu'il y a un thread qui bloque les autres a un moment donné.
les bons moteurs savent par exemple partager tout ce qui est affichage entre plusieurs cores vu que c'est une tache tres lourde.
le reste des taches etant a son tour placé sur differents cores comme: la physique sur un core, le son sur un autre, etc...
pour les taches les plus legeres un seul core peut en recevoir plusieurs, et pour les plus lourdes il est quasi impreatif qu'elles puissent etre reparties entre plusieurs cores.
dans un de nos jeux ici sorti sur xbox360 il y a qq années, quand le moteur avait été optimisé pour passer de 1 a 3 cores (la xbox360 a un tricore pour rappel) on avait gagné au moins +60 a +80% de fluidité.
c'est donc vraiment indispensable avec les moteurs recents d'avoir une bonne repartition entre les cores.
et de ce coté la, ca semble assez peu optimisé sur IL2COD.
ou en tous cas la charge cpu a l'air vraiment tres faible comparativement a la quantité de trucs a gerer et a afficher.
change le processaffinitymask= dans IL2 1946 et dis moi si tu gagne 1 seul fps en plus.
ca a déja été testé des dizaines de fois et ca ne change absolument rien.
Luthier a par contre répondu pour IL2 COD et a proposé aux simmers de tester IL2COD en mettant le processaffinitymask=1 pour le faire tourner sur un seul core afin de voir la difference.
je n'ai pas eut le temps d'essayer, mais je le ferais afin de voir.
par contre j'avais deja vérifié l'occupation cpu dans le gestionnaire de taches et m'etait etonné de voir que cette occupation cpu variait entre 19% et 45%. ce qui est effectivement faible comparé par exemple a ROF qui lui est tres bien multitreadé. et occupe entre 65 et 85% de mon cpu.
je suis donc d'avis qu'IL2 COD est bien multithreadé, mais pas suffisamment.
ou alors que le thread principal est trop gourmand par rapport aux autres. ce qui fiat qu'il y a un thread qui bloque les autres a un moment donné.
les bons moteurs savent par exemple partager tout ce qui est affichage entre plusieurs cores vu que c'est une tache tres lourde.
le reste des taches etant a son tour placé sur differents cores comme: la physique sur un core, le son sur un autre, etc...
pour les taches les plus legeres un seul core peut en recevoir plusieurs, et pour les plus lourdes il est quasi impreatif qu'elles puissent etre reparties entre plusieurs cores.
dans un de nos jeux ici sorti sur xbox360 il y a qq années, quand le moteur avait été optimisé pour passer de 1 a 3 cores (la xbox360 a un tricore pour rappel) on avait gagné au moins +60 a +80% de fluidité.
c'est donc vraiment indispensable avec les moteurs recents d'avoir une bonne repartition entre les cores.
et de ce coté la, ca semble assez peu optimisé sur IL2COD.
ou en tous cas la charge cpu a l'air vraiment tres faible comparativement a la quantité de trucs a gerer et a afficher.
P182, Z68XP UD3, I5 2500K@4,2Ghz, 12Go DDR3 PC12800 9 9 9 24, Asus Geforce GTX580 1,5Go, HDD 10.5To, PSU Antec 750W Bronze modulaire, Moniteur LG W2600HP-BF 26" LCD, FFB2, CH Product Pro Pedals, Track IR 2.
Crucial RealSSD C300 64Go.
Shane .Michel.
Crucial RealSSD C300 64Go.
Shane .Michel.
#3804
bon je me suis enfin mit a lire se thread sur simhq
si je comprend bien
y a un coeur dedier au son + l'affichage des texture en streaming et le reste au jeu
si je comprend bien
y a un coeur dedier au son + l'affichage des texture en streaming et le reste au jeu
#3805
Arrêtez moi si je dis une ânnerie ...
Si on arrivait à optimiser le multi-core ça voudrait dire que l'on pourrait charger plus efficacement les "gros" processeurs genre i5 ou i7 et que ça soulagerait les cartes graphiques qui de ce fait pourraient consacrer plus de ressources à un meilleur rendu graphique ?
Si on arrivait à optimiser le multi-core ça voudrait dire que l'on pourrait charger plus efficacement les "gros" processeurs genre i5 ou i7 et que ça soulagerait les cartes graphiques qui de ce fait pourraient consacrer plus de ressources à un meilleur rendu graphique ?
Zargos
-
- Chef de patrouille
- Messages : 4546
- Inscription : 05 décembre 2003
#3806
En fait, l'optimisation multi processeurs permettrait au soft d'aller coller des calculs sur les processeurs les plus délestés, et ainsi procéder à une répartition de la charge sur les différents coeurs... les anciennes versions de processeurs Intel ou AMD seraient aussi bénéficiaires de cette fonctionnalité, pas seulement les derniers joujoux sortis
#3807
bien evidemment.
comem dit plus haut, idealement la charge d'affichage devrait etre répartie sur 2 cores au moins, puis la pysique sur un autre et le son sur un autre.
si effectivement la seule chose qu'ils ont multithreadé c'est le son, forcement, ca peut pas etre bien fluide avec tout ce qu'il y a a gerer.
peut etre qu'ils auraient du dédier une partie du budget a faire former certains de leurs ingés au multithreading si ca n'a pas été fait.
je dis ca snas savoir ce qu'il en est, mais a l'heure actuelle ca merite un ingé a plein temps ce genre de taches. vu l'importance que ca peut avoir.
tiens pour voir faudrait que j'essaye ROF en mettant l'affinité sur un seul core afin de voir comment il se comporte. a mon avis ce sera un désastre.
comem dit plus haut, idealement la charge d'affichage devrait etre répartie sur 2 cores au moins, puis la pysique sur un autre et le son sur un autre.
si effectivement la seule chose qu'ils ont multithreadé c'est le son, forcement, ca peut pas etre bien fluide avec tout ce qu'il y a a gerer.
peut etre qu'ils auraient du dédier une partie du budget a faire former certains de leurs ingés au multithreading si ca n'a pas été fait.
je dis ca snas savoir ce qu'il en est, mais a l'heure actuelle ca merite un ingé a plein temps ce genre de taches. vu l'importance que ca peut avoir.
tiens pour voir faudrait que j'essaye ROF en mettant l'affinité sur un seul core afin de voir comment il se comporte. a mon avis ce sera un désastre.
P182, Z68XP UD3, I5 2500K@4,2Ghz, 12Go DDR3 PC12800 9 9 9 24, Asus Geforce GTX580 1,5Go, HDD 10.5To, PSU Antec 750W Bronze modulaire, Moniteur LG W2600HP-BF 26" LCD, FFB2, CH Product Pro Pedals, Track IR 2.
Crucial RealSSD C300 64Go.
Shane .Michel.
Crucial RealSSD C300 64Go.
Shane .Michel.
#3808
heu je crois que la question de zargos reposais justement sur le type de calcul...
a savoir si sa pouvais alleger la CG pour eviter de la fumée noire, ou si quoiqu'il arrive c'est indépendant et la CG morflera elle a fond
a savoir si sa pouvais alleger la CG pour eviter de la fumée noire, ou si quoiqu'il arrive c'est indépendant et la CG morflera elle a fond
#3809
Oktoberfest a écrit :LOL ! Déjà les premiers mods :D
Y a des zombies aussi ?????
et des booobs ???? :Jumpy:
#3810
non c'est pas comme ca que ca marche.
le fait de repartir mieux la charge sur les cores ne soulagera pas la carte graphique.c'est juste qu'actuellement qq chose dans le code bloque ou ralenti le cpu tellement que tout le programme freeze.
si la charge tait mieux repartie tout irait mieux.
mais il n'y a pas de transfert de cahrge entre cpu et carte graphique.
soit le proc envoie trop de choses a la CG et la cg ne peut plus suivre et le jeu se met a ramer (ce qui n'est pas le cas ici) soit le cpu est trop chargé sur un de ses cores, et la cg se tourne les pouces en attendant que le cpu lui envoie des trucs a afficher. et c'est plutot le cas ici.
preuve:
j'ai testé avec une GTX285 et avec une GTX580.
entre les deux evidemment les fps ne sont pas du tout les memes. ca va du simple a plus du double pour les memes settings.
mais les blocages comme ceux qui arrivent a l'approche d'un groupe de bombardiers sont les memes.
ils sont justes plus importants avec la 285.
dans un cas je tombe a 5fps dans l'autre cas je tombe a 9fps. alors qu'il n'y a pas grand chose a afficher (en plein ciel a 3000m d'altitude avec une douzaine de bombardiers.)
le fait de repartir mieux la charge sur les cores ne soulagera pas la carte graphique.c'est juste qu'actuellement qq chose dans le code bloque ou ralenti le cpu tellement que tout le programme freeze.
si la charge tait mieux repartie tout irait mieux.
mais il n'y a pas de transfert de cahrge entre cpu et carte graphique.
soit le proc envoie trop de choses a la CG et la cg ne peut plus suivre et le jeu se met a ramer (ce qui n'est pas le cas ici) soit le cpu est trop chargé sur un de ses cores, et la cg se tourne les pouces en attendant que le cpu lui envoie des trucs a afficher. et c'est plutot le cas ici.
preuve:
j'ai testé avec une GTX285 et avec une GTX580.
entre les deux evidemment les fps ne sont pas du tout les memes. ca va du simple a plus du double pour les memes settings.
mais les blocages comme ceux qui arrivent a l'approche d'un groupe de bombardiers sont les memes.
ils sont justes plus importants avec la 285.
dans un cas je tombe a 5fps dans l'autre cas je tombe a 9fps. alors qu'il n'y a pas grand chose a afficher (en plein ciel a 3000m d'altitude avec une douzaine de bombardiers.)
P182, Z68XP UD3, I5 2500K@4,2Ghz, 12Go DDR3 PC12800 9 9 9 24, Asus Geforce GTX580 1,5Go, HDD 10.5To, PSU Antec 750W Bronze modulaire, Moniteur LG W2600HP-BF 26" LCD, FFB2, CH Product Pro Pedals, Track IR 2.
Crucial RealSSD C300 64Go.
Shane .Michel.
Crucial RealSSD C300 64Go.
Shane .Michel.
#3811
Non, les CPU ne sont pas du tout adaptés aux calculs graphiques.
Et si vous voulez l'avis d'un programmeur de jeux-vidéos, je me permet de le donner:
Faire un jeu optimisé sur plusieurs CPU n'est pas, mais alors pas facile du tout. On ne peut pas paralléliser toutes les opérations, c'est très complexe.
La solution qu'a choisi 1C, c'est à dire celle de mettre 1 thread pour gérer le son et un autre pour streamer les textures, en plus du thread principal, est un peu la solution simple mais aller plus loin devient difficile.
Avec chance cependant, la simulation de vol est un genre de jeu qui permet de paralléliser certaines choses. Le calcul des modèles de vol peut très bien l'être, ainsi que l'IA.(chaque avion/ia s'update en parallèle des autres). Mais si logiquement c'est évident ça ne l'est jamais en pratique. Ca reste quelque chose de très complexe à mettre en place, et il faut le faire dès le début.
Et si on prend par exemple un I7 à six cœurs avec hyperthreading, ça permet de gérer 12 coeurs. C'est bien beau, mais avant de trouver comment compartimenter de façon logique son programme en 12 sous systèmes indépendants, il peut se passer beaucoup de temps.
C'est pour ça qu'a terme on s'oriente vers un système ou le compilo analyse, avec des balises mises par le programmeur, quelle partie du programme il est possible de mettre sur un autre thread. Ca permettra de simplifier le travail mais c'est encore loin d'être disponible et fonctionnel.
Et si vous voulez l'avis d'un programmeur de jeux-vidéos, je me permet de le donner:
Faire un jeu optimisé sur plusieurs CPU n'est pas, mais alors pas facile du tout. On ne peut pas paralléliser toutes les opérations, c'est très complexe.
La solution qu'a choisi 1C, c'est à dire celle de mettre 1 thread pour gérer le son et un autre pour streamer les textures, en plus du thread principal, est un peu la solution simple mais aller plus loin devient difficile.
Avec chance cependant, la simulation de vol est un genre de jeu qui permet de paralléliser certaines choses. Le calcul des modèles de vol peut très bien l'être, ainsi que l'IA.(chaque avion/ia s'update en parallèle des autres). Mais si logiquement c'est évident ça ne l'est jamais en pratique. Ca reste quelque chose de très complexe à mettre en place, et il faut le faire dès le début.
Et si on prend par exemple un I7 à six cœurs avec hyperthreading, ça permet de gérer 12 coeurs. C'est bien beau, mais avant de trouver comment compartimenter de façon logique son programme en 12 sous systèmes indépendants, il peut se passer beaucoup de temps.
C'est pour ça qu'a terme on s'oriente vers un système ou le compilo analyse, avec des balises mises par le programmeur, quelle partie du programme il est possible de mettre sur un autre thread. Ca permettra de simplifier le travail mais c'est encore loin d'être disponible et fonctionnel.
#3812
pour le site simhq. un moyen de savori si y'a vraiment que le son qui est multithredé, c'est simple:
tu benche avec son, puis tu rebenche sans son, si le fps ne change pas d'un poil, alors c'est ue le son est bien multithreadé.
si le moteur est bien fait, en reglant tous les niveaux sonores a 0, il ne devrait plus calculer les sons allegeant donc la charge cpu.
or si le son est bien multithreadé, dansle gestionnaire de taches on ne devrait plus voir qu'n seul core utilisé au lieu d'un core plus un peu d'un 2eme core.
car le son doit pas bouffer des masses sur le 2eme core quand meme.
tu benche avec son, puis tu rebenche sans son, si le fps ne change pas d'un poil, alors c'est ue le son est bien multithreadé.
si le moteur est bien fait, en reglant tous les niveaux sonores a 0, il ne devrait plus calculer les sons allegeant donc la charge cpu.
or si le son est bien multithreadé, dansle gestionnaire de taches on ne devrait plus voir qu'n seul core utilisé au lieu d'un core plus un peu d'un 2eme core.
car le son doit pas bouffer des masses sur le 2eme core quand meme.
P182, Z68XP UD3, I5 2500K@4,2Ghz, 12Go DDR3 PC12800 9 9 9 24, Asus Geforce GTX580 1,5Go, HDD 10.5To, PSU Antec 750W Bronze modulaire, Moniteur LG W2600HP-BF 26" LCD, FFB2, CH Product Pro Pedals, Track IR 2.
Crucial RealSSD C300 64Go.
Shane .Michel.
Crucial RealSSD C300 64Go.
Shane .Michel.
#3813
cartman, ah je suis tout a fait d'accord que c'est tres complexe a faire c'est d'ailleurs pour ca que j'ai signalé qu'avoir un ingé dédié a ce genre de tache me semble indispensable.
d'ailleurs en general dansles boites il y a le programmeur princpal qui coordonne les autres.
puis plusieurs ingés qui sont chacun spécialisés.
un pour la physique, un pour l'ia, un pour l'affichage, un pour le son, etc..
et donc il en faut aussi un pour la gestion du multithreading.
d'ailleurs en general dansles boites il y a le programmeur princpal qui coordonne les autres.
puis plusieurs ingés qui sont chacun spécialisés.
un pour la physique, un pour l'ia, un pour l'affichage, un pour le son, etc..
et donc il en faut aussi un pour la gestion du multithreading.
P182, Z68XP UD3, I5 2500K@4,2Ghz, 12Go DDR3 PC12800 9 9 9 24, Asus Geforce GTX580 1,5Go, HDD 10.5To, PSU Antec 750W Bronze modulaire, Moniteur LG W2600HP-BF 26" LCD, FFB2, CH Product Pro Pedals, Track IR 2.
Crucial RealSSD C300 64Go.
Shane .Michel.
Crucial RealSSD C300 64Go.
Shane .Michel.
#3814
Pas forcément soulager la partie GPU, mais plus charger les coeurs, oui. Prenons un exemple fictif :
Tu approches d'un Box de bombardier :
Un seul coeur est chargé du calcul des DM et les FM des bomber à tour de role plus la gestion du moteur de ton spit.
Un autre coeur s'occupe du son.
Un autre coeur s'occupe de regarder ou tu te trouves, vers ou tu avance, et précharge la map en avance.
Tu as un job qui prend beaucoup plus de temps que les autres. Il de vient le goulot d'étranglement.
On pourrait imaginer (mais c'est très facile à dire, avec des si.....) que les DM et FM des différents bomber soit calculés simultanément sur plusieur coeurs.
Le problème c'est que c'est pas forcément facile de faire ce découpage du code a posteriori. En developpant un moteur "from scratch", c'est le genre de chose auquel il faut penser dès le début.
Et Rise Of Flight a montré que c'était possible de faire ça correctement.
Mais bon, on nage en pleine spéculation avec pour seul infos des propos d'Oleg.
Edit :
Grillé.
Bon, le multi tache c'est certes balèze mais :
- en developpant un moteur en 2006, c'est un peu évident qu'il faut mettre le paquet là dessus.
- c'est balèze, mais c'est quand meme leur métier.
- d'autre jeu font ça très bien, comme Rise Of Flight.
Tu approches d'un Box de bombardier :
Un seul coeur est chargé du calcul des DM et les FM des bomber à tour de role plus la gestion du moteur de ton spit.
Un autre coeur s'occupe du son.
Un autre coeur s'occupe de regarder ou tu te trouves, vers ou tu avance, et précharge la map en avance.
Tu as un job qui prend beaucoup plus de temps que les autres. Il de vient le goulot d'étranglement.
On pourrait imaginer (mais c'est très facile à dire, avec des si.....) que les DM et FM des différents bomber soit calculés simultanément sur plusieur coeurs.
Le problème c'est que c'est pas forcément facile de faire ce découpage du code a posteriori. En developpant un moteur "from scratch", c'est le genre de chose auquel il faut penser dès le début.
Et Rise Of Flight a montré que c'était possible de faire ça correctement.
Mais bon, on nage en pleine spéculation avec pour seul infos des propos d'Oleg.
Edit :
Grillé.
Bon, le multi tache c'est certes balèze mais :
- en developpant un moteur en 2006, c'est un peu évident qu'il faut mettre le paquet là dessus.
- c'est balèze, mais c'est quand meme leur métier.
- d'autre jeu font ça très bien, comme Rise Of Flight.
#3815
désoler de remettre ca .Et la vitesse de la ram ca peut joué?
Asus P6T deluxe,Proc 920 I7 2.6 Oc 3.1,Mémoire Corsair 3x2 Gb DDR3 1600 XMS3,Disque dur 2x250Go raid 0,Alim Corsair TX 750w,
MSI 580gtx twin frozr II OC:Jumpy: Seven 64,Ecran Acer 1920x1200 60H.
:busted_reCliffs of Dover:busted_re
MSI 580gtx twin frozr II OC:Jumpy: Seven 64,Ecran Acer 1920x1200 60H.
:busted_reCliffs of Dover:busted_re
-
- Chef de patrouille
- Messages : 4546
- Inscription : 05 décembre 2003
#3817
Si tu as de la DDR2 à 233Mhz, tu risques en effet de mal la sentir passer... mais si tu es en DDR3, à moins de n'avoir que de la no name en low speed, ça ne devrait pas trop jouer sur les perfs...
#3818
d'après ce qui a été testé, quand le jeu est en pause, l'affichage est très fluide. ça n'est donc clairement pas la partie graphique qui fait peiner le proc, mais tout le reste.
#3819
Bonjour,
Je ne suis pas spécialiste mais j'ai cru comprendre que ROF savait tirer partie des multicores ?
Quelle solution a été retenue ?
A+ et bon vol
Je ne suis pas spécialiste mais j'ai cru comprendre que ROF savait tirer partie des multicores ?
Quelle solution a été retenue ?
A+ et bon vol
#3820
Si j'en crois ma vieille expérience qui date d'un temps que les moins de 20 ans ne peuvent pas connaitre : en théorie oui, puisque plus tu as de threads, plus tu vas aller puiser souvent dans la mémoire.Rototof a écrit :désoler de remettre ca .Et la vitesse de la ram ca peut joué?
Et donc, la vitesse de RAM consitue vite un goulot d'étranglement, sous réserve que :
- Tu as assez de RAM
- Tes threads sont tellement occupés qu'ils n'ont pas le temps d'aller récupérer les données dont ils ont besoin dans la RAM
Edit : si je dis des bêtises, n'hésitez pas à me donner un lien sur la maladie d'Alzheimer
"Tu as peur, Boyington, tu refuses le combat" (Tomio Arachi).
#3821
C'est facile Le son est géré par windows. Si vous voulez baisser le son dans Clodo, il faut faire un alt tab, et baisser le son dans le mélangeur windows. Bienvenue en 2011. Ah oui, pour la musique, c'est du on off, on la met ou on la met pas. Le menu sonore de Clodo. Relancez FB et allez voir le menu sonore. Allo Houston we have a problem. Ah, on me souffle dans l'oreillette que c'est du WIP, alors je me sens tout de suite rassuré.Shane a écrit :pour le site simhq. un moyen de savori si y'a vraiment que le son qui est multithredé, c'est simple:
tu benche avec son, puis tu rebenche sans son, si le fps ne change pas d'un poil, alors c'est ue le son est bien multithreadé.
si le moteur est bien fait, en reglant tous les niveaux sonores a 0, il ne devrait plus calculer les sons allegeant donc la charge cpu.
or si le son est bien multithreadé, dansle gestionnaire de taches on ne devrait plus voir qu'n seul core utilisé au lieu d'un core plus un peu d'un 2eme core.
car le son doit pas bouffer des masses sur le 2eme core quand meme.
Par contre, si vous avez de 2.0, 2.1, 3.1, 5.1, 7.1, vous allez en profitez. Ah oui, pour tester le son, c'est les effets windows, même pas un moteur.
#3822
Le contrôleur de mémoire est indépendant des cores. C'est lui qui sert à stocker, acheminer, et déplacer les octets calculés par les cores.jeanba a écrit :Si j'en crois ma vieille expérience qui date d'un temps que les moins de 20 ans ne peuvent pas connaitre : en théorie oui, puisque plus tu as de threads, plus tu vas aller puiser souvent dans la mémoire.
Et donc, la vitesse de RAM consitue vite un goulot d'étranglement, sous réserve que :Intuitivement, je dirais que quand on en sera là avec CloDo, on sera content
- Tu as assez de RAM
- Tes threads sont tellement occupés qu'ils n'ont pas le temps d'aller récupérer les données dont ils ont besoin dans la RAM
Edit : si je dis des bêtises, n'hésitez pas à me donner un lien sur la maladie d'Alzheimer
http://en.wikipedia.org/wiki/Memory_controller
#3823
http://forum.1cpublishing.eu/showthread.php?t=19644
Dev Report for 28 March
google translator
As the western version comes out 31th of the number we have patches with the changes laid out in the evening on the 30th. The exact content of it will be announced on the evening of 30th. Likely to be more and interim patches in the evening on the 29th. The size of patches will be quite small.
What to expect on the 31st:
1. Bids farewell to anti-epileptic, while you can. The other day it will disappear forever.
2. Optimized trees. Even cleaned up the memory.
3. The problem with the freezes at a close look at the operational bombers are not yet solved, but we kind of caught her by the tail.
4. Most probably hope that as we solve the problem with the physical model are not getting a message that broken-off wings.
5. Found that fix a bug in the last minute before release, when the sound is turned off at the cabin, "flew" forward, killed the binaural. I apologize to those who told me about this, and I just could not believe. Mend, tests.
6. Corrected texts of briefings and Subtitles radio reports.(rus)
7. Dramatically improved interface server/client multiplayer.
8. Removed the 16-bit resolution for all.
Well, the programmers are reading messages on bugs and small things for something clean. But as I said, the main priority for this week - to improve performance.
Asrock E3 890GX Phenom II X6 @4ghz avec Corsair H50 8go SSD OCZ agility2 HD6950@ 6970 Seven 64
Hulk of Dover Never before in the fields of human gaming has so much been promised by so few and not been delivered to so many.
Hulk of Dover Never before in the fields of human gaming has so much been promised by so few and not been delivered to so many.
#3825
kev-47 a écrit :Le contrôleur de mémoire est indépendant des cores. C'est lui qui sert à stocker, acheminer, et déplacer les octets calculés par les cores.
http://en.wikipedia.org/wiki/Memory_controller
Pour exécuter une tâche, le processeur a besoin d'une certaine quantité de données, si il ne les a pas, il est obligé d'attendre qu'on les lui fournisse, c'est le rôle du contrôleur de mémoire dont tu parles.
"Tu as peur, Boyington, tu refuses le combat" (Tomio Arachi).