En passant, mon ami m'a demandé a plusieurs reprises comment DÉTRUIRE un batiment plus tôt que de le prendre, sans obligatoirement utiliser d'arme de siège.
Ctrl + Clic droit ?
En passant il devrait y avoir un item "Apprendre à jouer" dans le menu principal avec toutes les commandes par défaut.
Une OOS ? Ça arrive assez souvent. Vérifie bien que vous utilisez tous les deux exactement la même version (qu'il n'y en ait pas un sur l'a19 et un autre sur la version svn, par exemple), et fais un ticket de bug, parce que c'est le genre de bug pas facile à détecter. Il est possible qu'on te demande d'envoyer ton commands.txt et d'autres fichiers de logs qui pourraient avoir été générés par le jeu suite à l'erreur.
Le gros problème quand on ramène ce sujet sur la table, c'est qu'on mélange très vite des trucs qui n'ont rien à voir, à savoir l'opposition citoyens vs citoyens-soldats, qui est une question qui se pose uniquement sur le plan du gameplay, et l'attribution d'un genre spécifique à une catégorie d'unités, qui est une question qui se pose purement sur le plan artistique. C'est complètement hors-sujet, je regrette déjà d'avoir écrit mon commentaire précédent.
Les questions sur la gameplay et les décisions de design ne sont pas le sujet de la dépêche, mais je vais juste faire une petite réponse concernant le sexisme :
0 A.D. tente d'être proche de la réalité historique et le gameplay et la partie artistique en dépendent plus ou moins lourdement. Notamment, la table des unités dans chaque civilisation est lourdement inspirée de la structure des civilisations "centrales" de la méditerranée, à savoir les civilisations grecques et romaines, à cette époque. Ces civilisations étaient extrêmement sexistes dans leur fonctionnement, les femmes et les hommes avaient chacun une place qui leur était réservée (notamment seuls les hommes faisaient la guerre, avaient un service militaire obligatoire, les femmes étaient cantonnées à certains métiers civils, etc.). Cela se reflète dans le jeu par la séparation entre deux types majeurs d'unités : les citoyennes et les citoyens-soldats. Les citoyennes ne peuvent effectuer que des activités économiques (ramasser des ressources et construire des bâtiments civils), alors que les citoyens-soldats peuvent exécuter toute activité économique ou militaire. Il existe une troisième catégorie majeure d'unité : les champions, qui ne peut effectuer que des activités militaires (et qui correspond historiquement à la progression d'une armée de citoyens mobilisés vers une armée de métier).
Le concept en lui-même ne me paraît pas déconnant, si c'est pour des questions de réalité historique, pourquoi pas. Par contre il y a des choses que je ne m'explique pas :
Pourquoi conserver le même paradigme pour les civilisations non basées sur la culture gréco-romaine ? Une organisation sexiste peut se comprendre pour les Athéniens, les Macédoniens, les Spartiates (encore que dans leur cas les citoyennes peuvent se battre et construire des palissades), les Romains, les Égyptiens, les Séleucides, probablement aussi les Carthaginois (très proches des grecs et des romains culturellement), peut-être aussi les Perses (même s'il y a eu au moins une femme dans les rangs des officiers perses, mais peut-être s'agit-il d'une exception), à la limite les Maurya (il y a eu des femmes dans l'armée maurya, mais celles-ci sont présentes dans le jeu via une catégorie de champions, les maiden guard), mais pourquoi garder la même organisation pour les peuples Celtes, réputés non-sexistes ? Je ne pense pas que les développeurs aient envie de complexifier le jeu en retirant le mécanisme citoyen-vs-citoyens-soldats pour les Celtes, mais il n'y a pas vraiment de raison à ce que les citoyens et les citoyens-soldats n'aient pas des variations mâles et femelles en égales proportions, à l'image des soldats Elfes et Hors-la-loi de Battle for Wesnoth, à part peut-être la charge de travail artistique supplémentaire.
Pourquoi ne pas faire des unités mâles similaires au citoyennes en terme de compétences ? À ma connaissance même dans la société grecque il y avait des hommes qui ne combattaient pas (des esclaves notamment). (En plus je viens de voir un truc : c'est d'autant plus vrai dans la société de la république romaine : il était très rare que des femmes labourent les champs, les matrones étaient exemptes de tâches agricoles et laissaient cela à leurs esclaves)
Pourquoi n'y a-t-il pas de mixité dans les unités de support autre que les citoyennes ? Les prêtres sont soit tous mâles (Grecs, Romains, Égyptiens, Séleucides, Celtes, Perses, Mauryas), soit tous femelles (Carthaginois, Ibères). Les marchants et pêcheurs sont toujours mâles. Alors qu'il y avait des femmes prêtres chez les Romains, les Égyptiens, les Celtes et les Mauryas, et des hommes prêtres chez les Ibères (je ne sais pas trop pour les Grecs, les Perses et les Carthaginois, il faudrait vérifier). Et les femmes exerçaient la pêche ou les métiers de commerce à peu près partout je pense.
Bref, j'ai un peu du mal à tout comprendre. Surtout pour les Celtes.
Je ne veux pas te créer du travail en plus, mais ce serait vraiment chouette de s'occuper de ça :)
Quand on viendra chez toi défoncer la porte, tout mettre en l'air chez toi, casser les meubles et la literies, le tout à 3 heures du matin, et en te disant "bye, ha au fait c'est à vos frais", des gens comme toi te répondront ton commentaire quand tu demanderas de l'aide.
Tu penses comme beaucoup que ça n'arrive qu'aux autres. Pour info, les "autres" pensaient comme toi avant que ça leur arrive.
Comme le dit le dicton : "On croit toujours que ça n'arrive qu'aux autres, pis le jour où ça arrive aux autres, on se dit : Pourvu que ça n'arrive qu'aux autres !" :/
Je pensais qu'être juste mentor permettait un investissement en temps assez faible (tout est relatif évidemment).
Bne non justement, en tout cas pas d'après les développeurs de 0 A.D.. D'après eux, il faudrait des développeurs connaissant bien le sujet qui soient constamment derrière les contributeurs du GSoC pour être sûr que le travail correspond bien à ce qui est attendu, et c'est autant de temps pris sur le développement au sein de l'équipe. Le regrettable épisode raté du travail payé par financement participatif (voir https://linuxfr.org/news/dernieres-evolutions-autour-de-0-a-d--2#am%C3%A9lioration-des-performances-et-campagne-de-dons ) n'a fait que confirmer les doutes des développeurs : les grosses contributions de fond, lorsqu'elles sont faites par un contributeur externe, nécessitent une vigilance et un investissement trop important. C'est pourquoi pour le pathfinder ils ont préféré avoir des membres de l'équipe de développement, qui connaissaient bien le code et à qui ils pouvaient faire confiance pour produire ce qui était attendu. J'imagine que ce serait pareil pour un travail avancé sur le multithreading.
Mettre les différentes parties (rendu graphique, moteur physique, IA,…) dans des threads différents. L'avantages c'est que c'est assez "facile" de porter un vieux moteur monothreadé. Un des soucis est que les différentes parties ne sont pas aussi gourmandes les unes que les autres, aussi on exploite pas forcément très efficacement la machine.
Voilà, c'est ça qui sera fait si j'ai bien compris. Il est notamment question de déplacer l'IA dans un autre thread, et probablement d'autres éléments. Et comme tu l'as expliqué, suivant la consommation de chaque élément, certains cœurs se retrouveront plus sollicités que d'autres. Ça ne devrait pas être trop grave car une fois que toutes les optimisations auront été faites, le jeu devrait tourner correctement avec les paramètres par défaut même en n'exploitant qu'un seul cœur. Et après ça le multithread, c'est du bénef' :)
Par contre il n'est pas question d'aller plus loin. Le moteur du jeu est très ancien et le modifier de manière à pouvoir séparer finement chacune des entités du jeu pour les faire tourner dans des threads en évitant tout conflit serait un travail colossal. Lorsque les problèmes de performances seront résolus et le multithread "basique" implémenté, on devrait être aux alentours de la fin de la période beta et de la sortie de la première version stable de 0 A.D. Part 1 : Empires Ascendant. Les développeurs seront alors déjà en train de travailler sur 0 A.D. Part 2 : Empires Besieged, qui devrait utiliser un nouveau moteur au lieu du vieillissant Pyrogenesis. Il est encore trop tôt pour dire si les développeurs vont écrire un Pyrogenesis 2 ou utiliser un moteur déjà existant (au moins pour le rendu).
Donc non, le multithreading "fin" de 0 A.D. Part 1 ne fait pas partie de la feuille de route de WFG parce qu'il n'ont probablement pas le temps ni l'effectif pour ça. Par contre oui, il est toujours possible qu'un jour des développeurs tiers se penchent sur la question (perso je ne tablerais pas dessus mais bon). Quant au GSoC, ça n'est pas non plus dans les moyens humains de WFG.
Et du coup le passage a du multi-thread est-il un chantier prévu ? J'imagine que le boulot doit être assez conséquent, mais on peut rêver. :)
Oui, mais :
1) Il faut optimiser le code du jeu avant de le multithreader. L'implémentation du multithread sera la dernière étape de la longue liste des optimisations à faire pour rendre le jeu plus rapide.
2) Le moteur de jeu est vieux et date d'avant les multicores. La séparation des tâches dans plusieurs threads est possible, mais elle ne sera jamais parfaite.
Hum d'une part si tu veux tester les capacités de ton hardware il existe des logiciels de benchmark pour ça (je pense à la phoronix test suite mais il y en a sûrement d'autres), d'autre part ces logiciels de benchmark lancent une batterie de tests sur ton matos, chaque test correspondant à une exploitation différente de celui-ci. Là par exemple, en minant des *coins, tu as tout juste testé les capacités de calcul OpenCL de ton GPU (et du driver associé, qui ne les exploite pas forcément de façon optimale), ce qui te permet de savoir comment se débrouille ton ordinateur par-rapport à d'autres ordinateurs en terme de calcul OpenCL, mais qui ne va pas te donner beaucoup d'indications sur comment il se débrouille sur les jeux 3D par exemple.
Edit: Après si ton objectif c'était de tester la ventilo, voir combien de temps ton PC pouvait tenir en surchauffe avant que ça plante, ouais, le minage de *coin est probablement un des meilleurs tests.
Par contre je ne m'attendais pas a ce que mon i5 soit aussi pourrave, je tourne avec … … … 2 FPS :P (et c'est juste en début de partie, j'imagine pas en 3 vs 3 avec 300 pop par culture :P )
Ce n'est pas très étonnant.
Déjà 0 A.D. est un jeu qui sollicite énormément le CPU, notamment à cause du code mal optimisé (des progrès ont été fait de ce côté-là mais il en reste beaucoup à faire). Alors si en plus tu lui demandes de faire des calculs qu'il a énormément de mal à faire (comme le dit illwieckz, c'est pas pour rien qu'on a inventé les GPU), il va se retrouver à plat assez vite. Et à cela il faut ajouter le fait que le jeu est pour l'instant monothreadé : un seul cœur du CPU est exploité. Je ne sais pas comment ça se passe avec le softpipe, si les opération GPU sont monothreadées aussi ou si elles sont réparties sur tout le CPU, mais elles sont monothreadées ça doit rendre les choses encore pire effectivement :)
En fait la plupart des options graphiques un peu poussées nécessitent GLSL d'activé pour fonctionner. GLSL a été activé par défaut récemment, probablement dans l'a19. Il faudrait reprendre le fichier de config des versions précédentes pour pouvoir désactiver GLSL sans risque (mais du coup ça va désactiver la plupart des autres options).
Pour information, j'ai tenté avec le clavier numérique a droite et ça ne fonctionnait pas non plus
Il ne doit pas être mappé par défaut alors, il faut le mapper soi-même. Dans le fichier de config les touches du keypad s'appellent "Num1", "Num2", etc. En cas de doute regarde le fichier keys.txt dans le répertoire de config.
Petite question: y a-t-il des échanges de codes, de bon procédé et de graphismes entre 0ad et les autres jeux? (genre TA Spring par exemple) :)
Je ne pense pas qu'il y ait des échanges de code avec Spring, 0 A.D. utilise son propre moteur : Pyrogenesis.
1) La possibilité de désactiver le GPU (surchauffe sur certains portable (genre Acer) peu importe l'OS) pour utiliser le CPU.
Je ne sais pas si c'est réaliste comme fonctionnalité, il y a d'autres jeux qui ont ça ? J'ai bien peur que déplacer les opérations GPU vers le CPU risque de faire ramer énormément le jeu (surtout pour 0 A.D.).
Mais bon si ça ne te paraît pas déconnant tu peux créer un rapport de bug (ça m'étonnerait qu'il y ait déjà un ticket qui demande ça).
En attendant je te conseille de désactiver la plupart des effets graphiques (ombres, particules, eau HD, etc.) pour solliciter le GPU le moins possible. Autre conseil : ne pas jouer sur un laptop, en tout cas pas de façon régulière. À l'exception de trucs très haut de gamme faits par des marques qui prennent les joueurs très aux sérieux, les laptops qu'on trouve dans le commerce de nos jours sont presque toujours fragiles, mal finis, mal ventilés, trop compacts, mal aérés, et ont une espérance de vie assez faible. Bref, pas fait pour le jeu (quoi qu'en disent les pubs).
Je n'arrive pas a grouper les unités, d'après ici http://trac.wildfiregames.com/wiki/HotKeys c'est CTRL+nombre pour grouper et nombre pour sélectionner (j'ai testé sur la version de base dans Ubuntu ainsi que la dernière version).
Les claviers français nécessitent de presser Shift pour accéder aux chiffres, et peu de jeux sont compatibles avec ce comportement. Il te faudra remapper ces touches, soit en remplaçant 12345… par &é"'(… etc soit en utilisant les touches du keypad.
Et on va pas aborder le sujet "software ouvert" non plus
J'espère bien parce que "software ouvert", ça ne veut rien dire. On dirait un mélange de "format ouvert" et "software libre", deux trucs qui n'ont rien à voir, combinés dans une expression bizarre qui embrouille la conversation plus qu'autre chose.
[^] # Re: Désync multiplayer
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 2.
Ctrl + Clic droit ?
En passant il devrait y avoir un item "Apprendre à jouer" dans le menu principal avec toutes les commandes par défaut.
*splash!*
[^] # Re: Désync multiplayer
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 2.
Ouais, voilà. Un exemple de ticket : http://trac.wildfiregames.com/ticket/3637
*splash!*
[^] # Re: Désync multiplayer
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 4. Dernière modification le 26 janvier 2016 à 12:08.
Une OOS ? Ça arrive assez souvent. Vérifie bien que vous utilisez tous les deux exactement la même version (qu'il n'y en ait pas un sur l'a19 et un autre sur la version svn, par exemple), et fais un ticket de bug, parce que c'est le genre de bug pas facile à détecter. Il est possible qu'on te demande d'envoyer ton commands.txt et d'autres fichiers de logs qui pourraient avoir été générés par le jeu suite à l'erreur.
*splash!*
[^] # Re: Représentation vs réalisme ?
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 3.
Même pendant la période ptolémaïque ?
*splash!*
[^] # Re: Représentation vs réalisme ?
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 3.
Le gros problème quand on ramène ce sujet sur la table, c'est qu'on mélange très vite des trucs qui n'ont rien à voir, à savoir l'opposition citoyens vs citoyens-soldats, qui est une question qui se pose uniquement sur le plan du gameplay, et l'attribution d'un genre spécifique à une catégorie d'unités, qui est une question qui se pose purement sur le plan artistique. C'est complètement hors-sujet, je regrette déjà d'avoir écrit mon commentaire précédent.
*splash!*
[^] # Re: Représentation vs réalisme ?
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 4.
Les questions sur la gameplay et les décisions de design ne sont pas le sujet de la dépêche, mais je vais juste faire une petite réponse concernant le sexisme :
0 A.D. tente d'être proche de la réalité historique et le gameplay et la partie artistique en dépendent plus ou moins lourdement. Notamment, la table des unités dans chaque civilisation est lourdement inspirée de la structure des civilisations "centrales" de la méditerranée, à savoir les civilisations grecques et romaines, à cette époque. Ces civilisations étaient extrêmement sexistes dans leur fonctionnement, les femmes et les hommes avaient chacun une place qui leur était réservée (notamment seuls les hommes faisaient la guerre, avaient un service militaire obligatoire, les femmes étaient cantonnées à certains métiers civils, etc.). Cela se reflète dans le jeu par la séparation entre deux types majeurs d'unités : les citoyennes et les citoyens-soldats. Les citoyennes ne peuvent effectuer que des activités économiques (ramasser des ressources et construire des bâtiments civils), alors que les citoyens-soldats peuvent exécuter toute activité économique ou militaire. Il existe une troisième catégorie majeure d'unité : les champions, qui ne peut effectuer que des activités militaires (et qui correspond historiquement à la progression d'une armée de citoyens mobilisés vers une armée de métier).
Le concept en lui-même ne me paraît pas déconnant, si c'est pour des questions de réalité historique, pourquoi pas. Par contre il y a des choses que je ne m'explique pas :
Pourquoi conserver le même paradigme pour les civilisations non basées sur la culture gréco-romaine ? Une organisation sexiste peut se comprendre pour les Athéniens, les Macédoniens, les Spartiates (encore que dans leur cas les citoyennes peuvent se battre et construire des palissades), les Romains, les Égyptiens, les Séleucides, probablement aussi les Carthaginois (très proches des grecs et des romains culturellement), peut-être aussi les Perses (même s'il y a eu au moins une femme dans les rangs des officiers perses, mais peut-être s'agit-il d'une exception), à la limite les Maurya (il y a eu des femmes dans l'armée maurya, mais celles-ci sont présentes dans le jeu via une catégorie de champions, les maiden guard), mais pourquoi garder la même organisation pour les peuples Celtes, réputés non-sexistes ? Je ne pense pas que les développeurs aient envie de complexifier le jeu en retirant le mécanisme citoyen-vs-citoyens-soldats pour les Celtes, mais il n'y a pas vraiment de raison à ce que les citoyens et les citoyens-soldats n'aient pas des variations mâles et femelles en égales proportions, à l'image des soldats Elfes et Hors-la-loi de Battle for Wesnoth, à part peut-être la charge de travail artistique supplémentaire.
Pourquoi ne pas faire des unités mâles similaires au citoyennes en terme de compétences ? À ma connaissance même dans la société grecque il y avait des hommes qui ne combattaient pas (des esclaves notamment). (En plus je viens de voir un truc : c'est d'autant plus vrai dans la société de la république romaine : il était très rare que des femmes labourent les champs, les matrones étaient exemptes de tâches agricoles et laissaient cela à leurs esclaves)
Pourquoi n'y a-t-il pas de mixité dans les unités de support autre que les citoyennes ? Les prêtres sont soit tous mâles (Grecs, Romains, Égyptiens, Séleucides, Celtes, Perses, Mauryas), soit tous femelles (Carthaginois, Ibères). Les marchants et pêcheurs sont toujours mâles. Alors qu'il y avait des femmes prêtres chez les Romains, les Égyptiens, les Celtes et les Mauryas, et des hommes prêtres chez les Ibères (je ne sais pas trop pour les Grecs, les Perses et les Carthaginois, il faudrait vérifier). Et les femmes exerçaient la pêche ou les métiers de commerce à peu près partout je pense.
Bref, j'ai un peu du mal à tout comprendre. Surtout pour les Celtes.
Tu parles à qui ?
*splash!*
[^] # Re: Quadrature du cercle...
Posté par eingousef . En réponse au journal Sortir de l'état d'urgence. Évalué à 4.
Comme le dit le dicton : "On croit toujours que ça n'arrive qu'aux autres, pis le jour où ça arrive aux autres, on se dit : Pourvu que ça n'arrive qu'aux autres !" :/
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 3.
Bne non justement, en tout cas pas d'après les développeurs de 0 A.D.. D'après eux, il faudrait des développeurs connaissant bien le sujet qui soient constamment derrière les contributeurs du GSoC pour être sûr que le travail correspond bien à ce qui est attendu, et c'est autant de temps pris sur le développement au sein de l'équipe. Le regrettable épisode raté du travail payé par financement participatif (voir https://linuxfr.org/news/dernieres-evolutions-autour-de-0-a-d--2#am%C3%A9lioration-des-performances-et-campagne-de-dons ) n'a fait que confirmer les doutes des développeurs : les grosses contributions de fond, lorsqu'elles sont faites par un contributeur externe, nécessitent une vigilance et un investissement trop important. C'est pourquoi pour le pathfinder ils ont préféré avoir des membres de l'équipe de développement, qui connaissaient bien le code et à qui ils pouvaient faire confiance pour produire ce qui était attendu. J'imagine que ce serait pareil pour un travail avancé sur le multithreading.
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 3. Dernière modification le 23 janvier 2016 à 22:38.
Voilà, c'est ça qui sera fait si j'ai bien compris. Il est notamment question de déplacer l'IA dans un autre thread, et probablement d'autres éléments. Et comme tu l'as expliqué, suivant la consommation de chaque élément, certains cœurs se retrouveront plus sollicités que d'autres. Ça ne devrait pas être trop grave car une fois que toutes les optimisations auront été faites, le jeu devrait tourner correctement avec les paramètres par défaut même en n'exploitant qu'un seul cœur. Et après ça le multithread, c'est du bénef' :)
Par contre il n'est pas question d'aller plus loin. Le moteur du jeu est très ancien et le modifier de manière à pouvoir séparer finement chacune des entités du jeu pour les faire tourner dans des threads en évitant tout conflit serait un travail colossal. Lorsque les problèmes de performances seront résolus et le multithread "basique" implémenté, on devrait être aux alentours de la fin de la période beta et de la sortie de la première version stable de 0 A.D. Part 1 : Empires Ascendant. Les développeurs seront alors déjà en train de travailler sur 0 A.D. Part 2 : Empires Besieged, qui devrait utiliser un nouveau moteur au lieu du vieillissant Pyrogenesis. Il est encore trop tôt pour dire si les développeurs vont écrire un Pyrogenesis 2 ou utiliser un moteur déjà existant (au moins pour le rendu).
Donc non, le multithreading "fin" de 0 A.D. Part 1 ne fait pas partie de la feuille de route de WFG parce qu'il n'ont probablement pas le temps ni l'effectif pour ça. Par contre oui, il est toujours possible qu'un jour des développeurs tiers se penchent sur la question (perso je ne tablerais pas dessus mais bon). Quant au GSoC, ça n'est pas non plus dans les moyens humains de WFG.
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 3.
Oui, mais :
1) Il faut optimiser le code du jeu avant de le multithreader. L'implémentation du multithread sera la dernière étape de la longue liste des optimisations à faire pour rendre le jeu plus rapide.
2) Le moteur de jeu est vieux et date d'avant les multicores. La séparation des tâches dans plusieurs threads est possible, mais elle ne sera jamais parfaite.
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 3. Dernière modification le 23 janvier 2016 à 13:46.
Hum d'une part si tu veux tester les capacités de ton hardware il existe des logiciels de benchmark pour ça (je pense à la phoronix test suite mais il y en a sûrement d'autres), d'autre part ces logiciels de benchmark lancent une batterie de tests sur ton matos, chaque test correspondant à une exploitation différente de celui-ci. Là par exemple, en minant des *coins, tu as tout juste testé les capacités de calcul OpenCL de ton GPU (et du driver associé, qui ne les exploite pas forcément de façon optimale), ce qui te permet de savoir comment se débrouille ton ordinateur par-rapport à d'autres ordinateurs en terme de calcul OpenCL, mais qui ne va pas te donner beaucoup d'indications sur comment il se débrouille sur les jeux 3D par exemple.
Edit: Après si ton objectif c'était de tester la ventilo, voir combien de temps ton PC pouvait tenir en surchauffe avant que ça plante, ouais, le minage de *coin est probablement un des meilleurs tests.
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 3.
Ce n'est pas très étonnant.
Déjà 0 A.D. est un jeu qui sollicite énormément le CPU, notamment à cause du code mal optimisé (des progrès ont été fait de ce côté-là mais il en reste beaucoup à faire). Alors si en plus tu lui demandes de faire des calculs qu'il a énormément de mal à faire (comme le dit illwieckz, c'est pas pour rien qu'on a inventé les GPU), il va se retrouver à plat assez vite. Et à cela il faut ajouter le fait que le jeu est pour l'instant monothreadé : un seul cœur du CPU est exploité. Je ne sais pas comment ça se passe avec le softpipe, si les opération GPU sont monothreadées aussi ou si elles sont réparties sur tout le CPU, mais elles sont monothreadées ça doit rendre les choses encore pire effectivement :)
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 4.
WHAT o_O
Tu mines des machin*coins avec le GPU de ton portable ? O_o Pas étonnant que tu niques ton matos ! Arrête tout de suite. C'est du suicide.
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 2.
En fait la plupart des options graphiques un peu poussées nécessitent GLSL d'activé pour fonctionner. GLSL a été activé par défaut récemment, probablement dans l'a19. Il faudrait reprendre le fichier de config des versions précédentes pour pouvoir désactiver GLSL sans risque (mais du coup ça va désactiver la plupart des autres options).
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 3.
Il ne doit pas être mappé par défaut alors, il faut le mapper soi-même. Dans le fichier de config les touches du keypad s'appellent "Num1", "Num2", etc. En cas de doute regarde le fichier keys.txt dans le répertoire de config.
Je ne pense pas qu'il y ait des échanges de code avec Spring, 0 A.D. utilise son propre moteur : Pyrogenesis.
Par contre il y a des échanges de graphismes : Stunt Rally a repris des modèles de 0 A.D. et cela a fait l'objet d'un journal sur Linuxfr.org : https://linuxfr.org/users/bluestorm/journaux/stunt-rally-course-de-voitures-reutilise-les-graphiques-de-0-a-d-strategie-antiquite Je ne sais pas si c'est définitif par contre.
*splash!*
# Crédits
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 8.
Les animation des algorithmes de pathfinding sont issues de Wikimedia Commons et sont sous CC by 3.0 :
https://en.wikipedia.org/wiki/File:Dijkstras_progress_animation.gif
https://en.wikipedia.org/wiki/File:Astar_progress_animation.gif
*splash!*
[^] # Re: Au moment de la publication, j'étais en train d'y jouer !
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 6.
Tu peux choisir entre différents niveaux d'IA dans l'écran Match Setup.
*splash!*
[^] # Re: gz
Posté par eingousef . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 6. Dernière modification le 22 janvier 2016 à 22:43.
Je ne sais pas si c'est réaliste comme fonctionnalité, il y a d'autres jeux qui ont ça ? J'ai bien peur que déplacer les opérations GPU vers le CPU risque de faire ramer énormément le jeu (surtout pour 0 A.D.).
Mais bon si ça ne te paraît pas déconnant tu peux créer un rapport de bug (ça m'étonnerait qu'il y ait déjà un ticket qui demande ça).
En attendant je te conseille de désactiver la plupart des effets graphiques (ombres, particules, eau HD, etc.) pour solliciter le GPU le moins possible. Autre conseil : ne pas jouer sur un laptop, en tout cas pas de façon régulière. À l'exception de trucs très haut de gamme faits par des marques qui prennent les joueurs très aux sérieux, les laptops qu'on trouve dans le commerce de nos jours sont presque toujours fragiles, mal finis, mal ventilés, trop compacts, mal aérés, et ont une espérance de vie assez faible. Bref, pas fait pour le jeu (quoi qu'en disent les pubs).
Les claviers français nécessitent de presser Shift pour accéder aux chiffres, et peu de jeux sont compatibles avec ce comportement. Il te faudra remapper ces touches, soit en remplaçant 12345… par &é"'(… etc soit en utilisant les touches du keypad.
*splash!*
[^] # Re: Bépo
Posté par eingousef . En réponse au journal Le gouvernement français veut changer de clavier. Évalué à 1.
Ceci dit Apple a déjà fait des format ouverts, par exemple ALAC. Si groumly connaissait bien cette entreprise il en aurait sûrement parlé :o
*splash!*
[^] # Re: Bépo
Posté par eingousef . En réponse au journal Le gouvernement français veut changer de clavier. Évalué à 5.
J'espère bien parce que "software ouvert", ça ne veut rien dire. On dirait un mélange de "format ouvert" et "software libre", deux trucs qui n'ont rien à voir, combinés dans une expression bizarre qui embrouille la conversation plus qu'autre chose.
*splash!*
[^] # Re: Bépo
Posté par eingousef . En réponse au journal Le gouvernement français veut changer de clavier. Évalué à 10.
On t'avait pourtant dit de ne pas le manger :/
*splash!*
[^] # Re: c'est peut-être parce que ton site tourne sous windows ?
Posté par eingousef . En réponse à la dépêche Le retour de la Méthode R.A.C.H.E. Évalué à 8.
voire télécharger de la poudre verte si ça persiste
*splash!*
[^] # Re: Contribuer au projet sans GitHub
Posté par eingousef . En réponse à la dépêche Le retour de la Méthode R.A.C.H.E. Évalué à 10.
Anéfé c'est emmaüs qui a inventé la demande de pull.
*splash!*
[^] # Re:Hécatombe
Posté par eingousef . En réponse au journal David Bowie bronsonisé. Évalué à 8.
tu en es sûr ? o_O
*splash!*
[^] # Re: Hécatombe
Posté par eingousef . En réponse au journal David Bowie bronsonisé. Évalué à 10.
En tout cas, ce ne sera pas m…
*SPLASH!**splash!*