Tu joues A quoi, gros ?
-
Klaim
- Artisan Digital
- Messages : 10635
- Enregistré le : mar. 27 mai 2003, 13:13
- Localisation : Paris
- Contact :
Clair, ça me rapelle plein de débats et suppositions aussi...yak a écrit :ce genre de discussion, ça me rappelle les debats risc/cisc... l'histoire est un eternel recommencement....
VV> Ben alors, t'es en programmation et tu sais pas ce que c'est que le multithreading? Ptete que tu connais le mot en français tu me diras...
Bah c'est un programme qui fait plusieurs choses au même moment. (pour traduire simplement aux non-initiés)
-
velo vert
- Génération Tchernobyl
- Messages : 7989
- Enregistré le : mer. 28 janv. 2004, 19:49
- Localisation : Made in Jussieu
je ne suis pas en progKlaim a écrit :VV> Ben alors, t'es en programmation et tu sais pas ce que c'est que le multithreading? Ptete que tu connais le mot en français tu me diras...
Bah c'est un programme qui fait plusieurs choses au même moment. (pour traduire simplement aux non-initiés)
. je suis en mesures physiques. avec des thermometres 
. et des torches a plasma 
(et quelques heures de C++, c'est vrai.)[/3615 mylife]plusieurs choses en meme temps. hmm. j'ai du mal a conceptualiser, mais je vais me contenter d'imaginer deux programmes qu'on fusionnerait en alternant une ligne sur deux. ca devrait suffir a ma conscience
.(4 smileys differents, j'explose mon reccord personnel.)
-
JeP
- Laborieux Optimiste
- Messages : 16496
- Enregistré le : mar. 23 déc. 2003, 10:49
- Localisation : fait de l'anim 3D à Paris (oui, j'ai changé)
- Contact :
Tiens c'est vrai ça... parce que de base... un programme s'éxécute ligne par ligne... est-ce que le multi-threading n'est permis qu'avec certains langages ?
Mais en même temps... dans le jeu, les images sont calculées, en même temps que l'IA et, disons, la physique. Alors comment ? (enfin si c'est possible d'espliquer simplement, en sachant que j'ai déjà fait un peu de prog... sinon tant pis)
Mais en même temps... dans le jeu, les images sont calculées, en même temps que l'IA et, disons, la physique. Alors comment ? (enfin si c'est possible d'espliquer simplement, en sachant que j'ai déjà fait un peu de prog... sinon tant pis)
TAMATAMATAMATAMA
Ben moi j'ai un exemple de multi threading, corrige moi si je me trompe klaim, avec les applis de chat, ou t'as un thread qui s'occupe de recevoir et d'afficer des messages de l'exterieur et un autre qui s'occupe de lire et envoyer ce que tu ecris, enfin en tout cas j'en avait programmé un comme ça en java y a quelque années...
GOD FINGER!!!!
-
Catox
- Otaking !
- Messages : 2783
- Enregistré le : mer. 16 avr. 2003, 13:22
- Localisation : Pertuis
- Contact :
Tiens, personne a parlé de Shadow of the Colossus...
Très content, mais un peu déçu quand même pour ce qui me concerne. entre 7 et 8 heures pour finir un jeu, ça gâche un peu, même si la fin est bien sympatoche. Pis le monde est vaste, mais vide quand même.
Sinon depuis que j'ai vu Oblivion bouger hier, je me demande si je vais pas mettre à jour mon PC ou même le changer tiens...
Mais je crains de pas accrocher le jeu... Genre Morrowind, y a une ambiance sympa, mais on sait pas trop quoi faire quoi.
Et y a Dragon Quest 8 qui arrive en avril aussi...
Très content, mais un peu déçu quand même pour ce qui me concerne. entre 7 et 8 heures pour finir un jeu, ça gâche un peu, même si la fin est bien sympatoche. Pis le monde est vaste, mais vide quand même.
Sinon depuis que j'ai vu Oblivion bouger hier, je me demande si je vais pas mettre à jour mon PC ou même le changer tiens...
Mais je crains de pas accrocher le jeu... Genre Morrowind, y a une ambiance sympa, mais on sait pas trop quoi faire quoi.
Et y a Dragon Quest 8 qui arrive en avril aussi...
Kataouh tataouh
-
Klaim
- Artisan Digital
- Messages : 10635
- Enregistré le : mar. 27 mai 2003, 13:13
- Localisation : Paris
- Contact :
A
VV> Ah ok... ben sinon arrête d'imaginer les choses comme ça ça dépends...
JeP>
atta je vais expliquer...
yak> Yep, mais ya un exemple encore plus simple :
En ce moment même vous utilisez un web-browser (IE ou Firefox par exemple).
Ce programme fait deux choses à la fois :
- il affiche une interface (fenetre + bouttons + icones + ce qu'il y a dans la page) ce qui est un programme qui tourne en boucle tout le temps;
- il attends que vous fassiez certaines choses (cliquer sur un boutton, tapper sur le clavier) et execute ce qui correspond.
Bon maintenant explications :
A la base, un processeur simple classique ne peut traiter qu'une instruction a la fois (pous simplifier, il ne fait qu'une chose a la fois comme copier des données, faire un calcul simple etc ).
Pourtant, vous voyez bien dans votre windows que ya plein de programmes qui marchent en même temps...alors comment se fait-il qu'une machine qui ne peut faire qu'une chose a la fois fasse plusieurs choses en même temps?
Et bien sachez que c'est une illusion !
Et oui, tout cela est "simulé" par l'OS (Windows par exemple) qui va simplement partager le temps de travail de chaque "processus" (programme disons) de façon extrêmement rapide ( 1Ghz = beaucoup beaucoup d'instructions executées à la seconde) en obligeant chaque processus a :
- s'executer pendant un temps t;
- puis se mettre en pause;
- passer à l'execution d'un autre processus pendant un temps t, etc...
Donc chacun leur tour, les processus (les programmes finalement) s'executent un peu, de façon plus ou moins équitable (selon leur priorité, puisque l'affichage par exemple devra s'executer plus souvent/vite que le reste) et se passent la main tellement rapidement qu'on a l'impression que la machine fait plusieurs choses en même temps.
Pourtant, ce n'est pas le cas et ça peut se voir par exemple quand un programme se met a accéder au disque dur de façon intempestive (cela coute beaucoup de temps a la machine) ben tout le reste est ralentis.
C'est ce qui fait que par exemple si vous tentez d'encoder une vidéo en même temps d'en lire une autre, ça va rammer comme pas possible.
Tout cela est vrai avec un processeur.
Cela deviens interessant quand il y a plus d'un processeur, car dans ce cas l'OS peut départager "physiquement" les executions de processus entre les processeurs.
Jusque récemment par exemple, on avait tout simplement des machine avec plusieurs processeurs. Mais aujourd'hui on sait faire des processeur qui sont physiquement plusieurs processeur en 1 (par exemple les BiCore qui se présentent sous la forme d'un processeur classique mais qui ont réellement 2 processeur dedans).
Avec ce genre de processeurs, on a donc réellement plusieurs processus/programmes qui s'éxecutent réellement en même temps. (Bien que BiCore = 2 Processeurs donc c'est départagé en 2).
Ce que j'ai oublié de préciser c'est qu'un processus/programme peut lui même se diviser en différents sous programmes qui s'executent en parrallèle, c'est ce qu'on appelle les threads.
Donc avec un bicore voir multi-core (ou juste multi-proc), un programme/processus, qui a plusieurs threads, va s'executer plus rapidement parceque les différents threads seront partagés et exécutés par différents processeurs.
C'est le cas de toutes les applications comme les jeux multijoueur ou les chats genr IRC : comme l'explique yak, ya un petit programme (un thread) qui tourne en boucle pour vérifier en permanence si ya un message qui est reçu. Pendant ce temps l'autre thread ne fait qu'attendre que l'utilisateur tappe quelque chose ou qu'un message, récupéré par le premier thread, soit reçu pour s'en occuper.
Là où c'est tendu comme un slip : imaginez un programme qui fait deux choses à la fois sur les mêmes données. Que ce passe-t-il lorsque les deux threads tentent d'écrire en même temps au même endroit d'un disque dur, ou qu'un thread tente de lire une donnée alors qu'un autre tente d'écrire dessus au même moment? Et ben ça provoque une putain d'erreur, et ouais, parceque c'est tout simplement pas logique.
Donc ya des techniques pour faire en sorte que ça arrive jamais : on fait en sorte que les données qui sont partagées entre les différents threads ne soient accéssibles que par un seul thread a la fois. Les autres threads peuvent soit attendre d'avoir enfin l'accès aux données, soit passer a autre chose parcequ'ils ont pas que ça a foutre.
Du coup, on perds de la rapidité gagnée par le fait que ce soit en parrallèle puisque les threads s'attendent les uns les autres...
Mais cela relève d'un problème d'organisation : si les choses sont bien organisé dans un programme, la perte de temps due a ce probleme peut devenir minime. Mais c'est vraiment dur a obtenir dans certains cas, par exemple dans les jeux.
Donc, sachant tout cela, revenons à la PS3 :
Processeur CELL :
- 1 Core équivalent à un PowerPC (ex-processeurs des derniers macs)
- 7 Core "sygernetics" spécialisés
En gros, le premier core est un gros processeur, et les autres des bon processeurs que le premier peut organiser comme il veut pour que tel processeur travaille sur tel partie du programme pendant que ces deux là travailelnt sur ça et puis ceux là vont se tapper ce boulot là.
Donc gros potentiel pour une application bien construite autour de cette machine, en exploitant un max le fait qu'on puisse profiter des différents cores.
Pour revenir aux jeux en particulier :
en réalité, un jeu c'est (généralement) une boucle sans fin qui : récupère les entrées (clavier/souris par exemple), traite les informations (execute les règles du jeu, la physique etc), prépare les données des ressources (place/déplace les modèles 3D, lance un son, une musique) et enfin execute le rendu du jeu (c'est à dire affiche une image et joue un bout de son/musique).
Et ensuite ça recommence.
Du coup c'es tun peu comme le principe du cinéma : on enchaine des images tellement rapidement qu'on a le mouvement (c'est pas tout a fait pareil pour le son toutefois). Seulement dans les jeux, entre chaque image il peut y avoir des trucs qui se passent et qui vont déterminer la prochaine image (d'où la possibilité d'interraction).
Lorsque le jeu est multijoueur, ça se passe comme dans l'exemple de yak : ya un thread qui est créé et qui en parrallèle ne s'occupe que de recevoir les messages distants pour les refiler à la "boucle principale" pour qu'elle les prenne en compte au prochain "cycle".
Donc, non , l'affichage ne se fait pas en même temps que le reste, il se fait au bout de traitements qui servent justement a déterminer, à la fin, ce qui a changé graphiquement. Ensuite on balance les infos de l'image a construire à la carte graphique, et elle s'occupe (en parrallèle par contre, mais gérée par le driver) de retransmettre ça en une image 2D qui sera affichée au final à l'écran (ou dans la fenetre).
Hmm on va un peu loin là...
Mais disons que avec un processeur classique, faire du multithreading a toutes les chances de ralentir le jeu à mort, parceque c'est simulé. Tandis qu'avec de vrais cores séparés, ce n'est plus simulé, du coup ça va réellement en parrallèle, sauf pour les accès aux données partagées entre les threads.
Pour vous donner une idée, un jeu ou on voyage sur un immense terrain qui se charge au fur et a mesure :
- dans le cas ou il est prévu pourun processeur classique et qu'il y a effectivement un processeur classique sur la machine : ben ça va être lent si c'est multithreadé (et un peu aproximatif) alors on fera de petits chargements a chaque fois qu'on avance de tel distance d; pas de multithread.
- dans le cas ou on a une machine avec plusieurs core ET que le jeu en tiens compte, ben le mieu c'est d'y aller a coeur joie (mais pas trop) avec les threads: un thread qui s'occupe uniquement de charger les données du jeu au fur et a mesure des distances parcourues par le joueur.
Sachez que quasimment toutes les consoles ont plusieurs processeurs, seulement la façon de s'en servir, le nombre de proc et les spécialisations de chaque proc diffère selon les consoles.
C'est ce qui fait que la PS2 est théoriquement puissante mais difficile à programmer (aussi parcequ'il y a de sl'assembleur, ce qui reviens un peu a assembler des molécules pour faire un avion...) [...]
En gros, dés le moment ou un programme/jeu est multi-thread, si il tourne sur une machine multi-core ET (et c'est très important) qu'il exploite bien la machine ET (encore plus important) qu'il est bien organisé (avec synchronisation entre les threads poru éviter qu'ils s'attendent entre eux) ben ya moyen de faire des trucs de ouf gueudin.
Comme par exemple faire gérer la physique par une partie de la machine pendant que le reste s'ooccupe du jeu, et puis uen autre partie qui ne s'occupe que d el'affichage. C'es tun cas idéal qui est pas super ateignable mais bon.
...
Heu...vous avez compris quelque chose? J'ai un peu parlé de tout là, c'est un peu le bordel....
Argh...
JeP>
...Tiens c'est vrai ça... parce que de base... un programme s'éxécute ligne par ligne... est-ce que le multi-threading n'est permis qu'avec certains langages ?
atta je vais expliquer...
Ben en gros ce que tu dis c'est n'importe quoi, désolé ^__^;;;;;;Mais en même temps... dans le jeu, les images sont calculées, en même temps que l'IA et, disons, la physique. Alors comment ? (enfin si c'est possible d'espliquer simplement, en sachant que j'ai déjà fait un peu de prog... sinon tant pis)
yak> Yep, mais ya un exemple encore plus simple :
En ce moment même vous utilisez un web-browser (IE ou Firefox par exemple).
Ce programme fait deux choses à la fois :
- il affiche une interface (fenetre + bouttons + icones + ce qu'il y a dans la page) ce qui est un programme qui tourne en boucle tout le temps;
- il attends que vous fassiez certaines choses (cliquer sur un boutton, tapper sur le clavier) et execute ce qui correspond.
Bon maintenant explications :
A la base, un processeur simple classique ne peut traiter qu'une instruction a la fois (pous simplifier, il ne fait qu'une chose a la fois comme copier des données, faire un calcul simple etc ).
Pourtant, vous voyez bien dans votre windows que ya plein de programmes qui marchent en même temps...alors comment se fait-il qu'une machine qui ne peut faire qu'une chose a la fois fasse plusieurs choses en même temps?
Et bien sachez que c'est une illusion !
Et oui, tout cela est "simulé" par l'OS (Windows par exemple) qui va simplement partager le temps de travail de chaque "processus" (programme disons) de façon extrêmement rapide ( 1Ghz = beaucoup beaucoup d'instructions executées à la seconde) en obligeant chaque processus a :
- s'executer pendant un temps t;
- puis se mettre en pause;
- passer à l'execution d'un autre processus pendant un temps t, etc...
Donc chacun leur tour, les processus (les programmes finalement) s'executent un peu, de façon plus ou moins équitable (selon leur priorité, puisque l'affichage par exemple devra s'executer plus souvent/vite que le reste) et se passent la main tellement rapidement qu'on a l'impression que la machine fait plusieurs choses en même temps.
Pourtant, ce n'est pas le cas et ça peut se voir par exemple quand un programme se met a accéder au disque dur de façon intempestive (cela coute beaucoup de temps a la machine) ben tout le reste est ralentis.
C'est ce qui fait que par exemple si vous tentez d'encoder une vidéo en même temps d'en lire une autre, ça va rammer comme pas possible.
Tout cela est vrai avec un processeur.
Cela deviens interessant quand il y a plus d'un processeur, car dans ce cas l'OS peut départager "physiquement" les executions de processus entre les processeurs.
Jusque récemment par exemple, on avait tout simplement des machine avec plusieurs processeurs. Mais aujourd'hui on sait faire des processeur qui sont physiquement plusieurs processeur en 1 (par exemple les BiCore qui se présentent sous la forme d'un processeur classique mais qui ont réellement 2 processeur dedans).
Avec ce genre de processeurs, on a donc réellement plusieurs processus/programmes qui s'éxecutent réellement en même temps. (Bien que BiCore = 2 Processeurs donc c'est départagé en 2).
Ce que j'ai oublié de préciser c'est qu'un processus/programme peut lui même se diviser en différents sous programmes qui s'executent en parrallèle, c'est ce qu'on appelle les threads.
Donc avec un bicore voir multi-core (ou juste multi-proc), un programme/processus, qui a plusieurs threads, va s'executer plus rapidement parceque les différents threads seront partagés et exécutés par différents processeurs.
C'est le cas de toutes les applications comme les jeux multijoueur ou les chats genr IRC : comme l'explique yak, ya un petit programme (un thread) qui tourne en boucle pour vérifier en permanence si ya un message qui est reçu. Pendant ce temps l'autre thread ne fait qu'attendre que l'utilisateur tappe quelque chose ou qu'un message, récupéré par le premier thread, soit reçu pour s'en occuper.
Là où c'est tendu comme un slip : imaginez un programme qui fait deux choses à la fois sur les mêmes données. Que ce passe-t-il lorsque les deux threads tentent d'écrire en même temps au même endroit d'un disque dur, ou qu'un thread tente de lire une donnée alors qu'un autre tente d'écrire dessus au même moment? Et ben ça provoque une putain d'erreur, et ouais, parceque c'est tout simplement pas logique.
Donc ya des techniques pour faire en sorte que ça arrive jamais : on fait en sorte que les données qui sont partagées entre les différents threads ne soient accéssibles que par un seul thread a la fois. Les autres threads peuvent soit attendre d'avoir enfin l'accès aux données, soit passer a autre chose parcequ'ils ont pas que ça a foutre.
Du coup, on perds de la rapidité gagnée par le fait que ce soit en parrallèle puisque les threads s'attendent les uns les autres...
Mais cela relève d'un problème d'organisation : si les choses sont bien organisé dans un programme, la perte de temps due a ce probleme peut devenir minime. Mais c'est vraiment dur a obtenir dans certains cas, par exemple dans les jeux.
Donc, sachant tout cela, revenons à la PS3 :
Processeur CELL :
- 1 Core équivalent à un PowerPC (ex-processeurs des derniers macs)
- 7 Core "sygernetics" spécialisés
En gros, le premier core est un gros processeur, et les autres des bon processeurs que le premier peut organiser comme il veut pour que tel processeur travaille sur tel partie du programme pendant que ces deux là travailelnt sur ça et puis ceux là vont se tapper ce boulot là.
Donc gros potentiel pour une application bien construite autour de cette machine, en exploitant un max le fait qu'on puisse profiter des différents cores.
Pour revenir aux jeux en particulier :
en réalité, un jeu c'est (généralement) une boucle sans fin qui : récupère les entrées (clavier/souris par exemple), traite les informations (execute les règles du jeu, la physique etc), prépare les données des ressources (place/déplace les modèles 3D, lance un son, une musique) et enfin execute le rendu du jeu (c'est à dire affiche une image et joue un bout de son/musique).
Et ensuite ça recommence.
Du coup c'es tun peu comme le principe du cinéma : on enchaine des images tellement rapidement qu'on a le mouvement (c'est pas tout a fait pareil pour le son toutefois). Seulement dans les jeux, entre chaque image il peut y avoir des trucs qui se passent et qui vont déterminer la prochaine image (d'où la possibilité d'interraction).
Lorsque le jeu est multijoueur, ça se passe comme dans l'exemple de yak : ya un thread qui est créé et qui en parrallèle ne s'occupe que de recevoir les messages distants pour les refiler à la "boucle principale" pour qu'elle les prenne en compte au prochain "cycle".
Donc, non , l'affichage ne se fait pas en même temps que le reste, il se fait au bout de traitements qui servent justement a déterminer, à la fin, ce qui a changé graphiquement. Ensuite on balance les infos de l'image a construire à la carte graphique, et elle s'occupe (en parrallèle par contre, mais gérée par le driver) de retransmettre ça en une image 2D qui sera affichée au final à l'écran (ou dans la fenetre).
Hmm on va un peu loin là...
Mais disons que avec un processeur classique, faire du multithreading a toutes les chances de ralentir le jeu à mort, parceque c'est simulé. Tandis qu'avec de vrais cores séparés, ce n'est plus simulé, du coup ça va réellement en parrallèle, sauf pour les accès aux données partagées entre les threads.
Pour vous donner une idée, un jeu ou on voyage sur un immense terrain qui se charge au fur et a mesure :
- dans le cas ou il est prévu pourun processeur classique et qu'il y a effectivement un processeur classique sur la machine : ben ça va être lent si c'est multithreadé (et un peu aproximatif) alors on fera de petits chargements a chaque fois qu'on avance de tel distance d; pas de multithread.
- dans le cas ou on a une machine avec plusieurs core ET que le jeu en tiens compte, ben le mieu c'est d'y aller a coeur joie (mais pas trop) avec les threads: un thread qui s'occupe uniquement de charger les données du jeu au fur et a mesure des distances parcourues par le joueur.
Sachez que quasimment toutes les consoles ont plusieurs processeurs, seulement la façon de s'en servir, le nombre de proc et les spécialisations de chaque proc diffère selon les consoles.
C'est ce qui fait que la PS2 est théoriquement puissante mais difficile à programmer (aussi parcequ'il y a de sl'assembleur, ce qui reviens un peu a assembler des molécules pour faire un avion...) [...]
En gros, dés le moment ou un programme/jeu est multi-thread, si il tourne sur une machine multi-core ET (et c'est très important) qu'il exploite bien la machine ET (encore plus important) qu'il est bien organisé (avec synchronisation entre les threads poru éviter qu'ils s'attendent entre eux) ben ya moyen de faire des trucs de ouf gueudin.
Comme par exemple faire gérer la physique par une partie de la machine pendant que le reste s'ooccupe du jeu, et puis uen autre partie qui ne s'occupe que d el'affichage. C'es tun cas idéal qui est pas super ateignable mais bon.
...
Heu...vous avez compris quelque chose? J'ai un peu parlé de tout là, c'est un peu le bordel....
Argh...
-
Klaim
- Artisan Digital
- Messages : 10635
- Enregistré le : mar. 27 mai 2003, 13:13
- Localisation : Paris
- Contact :
Catox >
Jettez un oeil aux vidéos qu'ils balancent tous les jours depuis hier, ça fait peur : http://www.elderscrolls.com/downloads/media_movies.htm
Plus que 6 jours
Sinon pour le fait que tu sais pas quoi faire dans morrowind, c'est un problème de conception :
1) Les quêtes sont pas super bien rangées dans ton livre de quête -> Tu t'y retrouves plus , donc tu sais plus ce que tu dois faire ensuite, quelle quête est interessante ou pas etc
2) La quête principale est un bon fil mais unpeu complexe -> des fois tu dois lire des textes fastidieux pour savoir où aller, et là je joueur lambda vire le jeu direct
3) c'est un peu statique...manque de vie
4) je te parle même pas des combats...
5) parfois, tu mets plusieurs heures temps réel a aller à un endroit où tu est déjà passé...
Tout ça est corrigé dans oblivion:
- toutes les quêtes sont clairement résumées, avec des objectifs clairs, et une boussole qui t'indique où aller! (mais t'es pas obligé de l'utilisé si tu te sents trop assisté...)
- le journal est sacrément plus clair, et surtout bien organisé
- tu peux te déplacer à cheval poru aller plsu vite (tu l'achetes, le vol ou l'apprivoise héhé)
- tu peux voyager automatiquement vers tous les endroits où t'es déjà allé, le seul truc c'est que tu rates les détails du voyage , mais bon si t'as pas que ça a foutre ben c'est très pratique!
- les combats ressemblent a des combats
etc
en gros ils ont fait quasimment que prendre le bon de morrowind, virer et revoir complètement le mauvais, et enfin amélirere ce qu'ils ont obtenu.
Moi j'attends de voir avec impatience si ils ont réussi leur coup, mais je sis que sur la plupart des points c'est déjà gagné (je le sais par divers moyens que j'expliquerai un autre jour parcequ bon).
Vala.
Ben moi je vais pouvoir le faire tourner a fond apparemment, vu que j'ai un bicore, qu'il exploite les bicore, et que j'ai une bien grosse carte graphique.Sinon depuis que j'ai vu Oblivion bouger hier, je me demande si je vais pas mettre à jour mon PC ou même le changer tiens...
Mais je crains de pas accrocher le jeu... Genre Morrowind, y a une ambiance sympa, mais on sait pas trop quoi faire quoi.
Jettez un oeil aux vidéos qu'ils balancent tous les jours depuis hier, ça fait peur : http://www.elderscrolls.com/downloads/media_movies.htm
Plus que 6 jours
Sinon pour le fait que tu sais pas quoi faire dans morrowind, c'est un problème de conception :
1) Les quêtes sont pas super bien rangées dans ton livre de quête -> Tu t'y retrouves plus , donc tu sais plus ce que tu dois faire ensuite, quelle quête est interessante ou pas etc
2) La quête principale est un bon fil mais unpeu complexe -> des fois tu dois lire des textes fastidieux pour savoir où aller, et là je joueur lambda vire le jeu direct
3) c'est un peu statique...manque de vie
4) je te parle même pas des combats...
5) parfois, tu mets plusieurs heures temps réel a aller à un endroit où tu est déjà passé...
Tout ça est corrigé dans oblivion:
- toutes les quêtes sont clairement résumées, avec des objectifs clairs, et une boussole qui t'indique où aller! (mais t'es pas obligé de l'utilisé si tu te sents trop assisté...)
- le journal est sacrément plus clair, et surtout bien organisé
- tu peux te déplacer à cheval poru aller plsu vite (tu l'achetes, le vol ou l'apprivoise héhé)
- tu peux voyager automatiquement vers tous les endroits où t'es déjà allé, le seul truc c'est que tu rates les détails du voyage , mais bon si t'as pas que ça a foutre ben c'est très pratique!
- les combats ressemblent a des combats
etc
en gros ils ont fait quasimment que prendre le bon de morrowind, virer et revoir complètement le mauvais, et enfin amélirere ce qu'ils ont obtenu.
Moi j'attends de voir avec impatience si ils ont réussi leur coup, mais je sis que sur la plupart des points c'est déjà gagné (je le sais par divers moyens que j'expliquerai un autre jour parcequ bon).
Vala.
-
velo vert
- Génération Tchernobyl
- Messages : 7989
- Enregistré le : mer. 28 janv. 2004, 19:49
- Localisation : Made in Jussieu
ouais j'ai tout compris. je crois. je rentabilise enfin mes cours d'info ^-^.Heu...vous avez compris quelque chose? J'ai un peu parlé de tout là, c'est un peu le bordel....
par contre un truc :
ton assembleur, c'est le meme langage de prog que celui pour les microcontroleurs ? si oui, ca doit effectivement etre un truc de fous furieux (d'apres ce que j'ai compris de l'assembleur), qu'est-ce qu'ils leurs ont pris de faire ca, chez sony ?aussi parcequ'il y a de sl'assembleur
ouais je sais... mais t'imagines meme pas comment la vie est plus douce quand on s'imagine des choses comme ça...VV> Ah ok... ben sinon arrête d'imaginer les choses comme ça ça dépends...
-
Klaim
- Artisan Digital
- Messages : 10635
- Enregistré le : mar. 27 mai 2003, 13:13
- Localisation : Paris
- Contact :
Ah oui donc JeP :
Le Multithreading peut ne pas être accessible par un langage, dans le cas ou ce langace ne touche pas à la machine ou a l'OS.
En réalité, dés le moment ou le langage peut accéder à l'OS, c'est l'OS qui lui fournis de quoi faire du multithreading.
Putain je me rends compte a quel point j'ai une connaissance poussée de certains trucs...
...dire qu'ya des gars largement plus balaise que moi et qui sont même pas connus...
...putain j'ai du chemin a faire...
Courage!
Le Multithreading peut ne pas être accessible par un langage, dans le cas ou ce langace ne touche pas à la machine ou a l'OS.
En réalité, dés le moment ou le langage peut accéder à l'OS, c'est l'OS qui lui fournis de quoi faire du multithreading.
Putain je me rends compte a quel point j'ai une connaissance poussée de certains trucs...
...dire qu'ya des gars largement plus balaise que moi et qui sont même pas connus...
...putain j'ai du chemin a faire...
Courage!
-
Catox
- Otaking !
- Messages : 2783
- Enregistré le : mer. 16 avr. 2003, 13:22
- Localisation : Pertuis
- Contact :
j'suis presque rassuré ^^
Ce qui me pose le plus de souci se rapproche de "quelle quête est intéressante ou pas" et de "ce qu'il faut faire"... et ça se mixe en gros en fil conducteur général. J'suis trop habitué à la narration des rpg console japonais. Et je parle pas de la linéarité mais plutôt de la façon dont l'histoire parait intense et touche le joueur directement. L'opposé direct, pour moi, sont les jeux tels que Baldur's Gate.
Dans la famille perdu, genre on m'envoit chercher un objet dans les ruines Truc, mais sans me dire où elles sont ni qui va pouvoir m'en parler... j'suis bien avancé.
Mais ce que tu décris a l'air quand même mieux... je doute quand même sur la narration.
Ce qui me pose le plus de souci se rapproche de "quelle quête est intéressante ou pas" et de "ce qu'il faut faire"... et ça se mixe en gros en fil conducteur général. J'suis trop habitué à la narration des rpg console japonais. Et je parle pas de la linéarité mais plutôt de la façon dont l'histoire parait intense et touche le joueur directement. L'opposé direct, pour moi, sont les jeux tels que Baldur's Gate.
Dans la famille perdu, genre on m'envoit chercher un objet dans les ruines Truc, mais sans me dire où elles sont ni qui va pouvoir m'en parler... j'suis bien avancé.
Mais ce que tu décris a l'air quand même mieux... je doute quand même sur la narration.
Kataouh tataouh
