rewind a écrit 3425 commentaires

GNOME Maps veut proposer des tuiles dans son appli ? Très bien, il faut alors le service associé, et surtout indépendant de n'importe quel fournisseur. S'ils ne sont pas capables de ne pas dépendre d'un tiers pour la fourniture de tuiles, alors ils devraient enlever cette fonctionnalité (instant troll : en plus, c'est un peu une spécialité d'enlever des fonctionnalités chez GNOME ; fin de l'instant troll). Pour le coup, l'appli, ce n'est pas que le binaire chez le client, c'est aussi le service de tuiles.

Pour moi, ce genre de péripétie pose quand même la question des compromis qui sont fait avec la liberté. Je veux dire par là que des gens qui font du logiciel libre, ils savent faire la différence entre libre et gratuit, et donc ils savent qu'en utilisant un truc seulement gratuit, ils s'exposent à avoir des problèmes dans ce genre tôt ou tard. Alors pourquoi est-ce qu'ils font ça ? Ma seule réaction, ça serait de dire : bien fait !

Quelqu'un qui se rallie à mes arguments, me témoigne de la sympathie, et fait un effort pour défendre mes convictions, je veux bien le qualifier d'ami.

Donc, Marine Le Pen est ton amie ? Non, je dis ça mais les députés FN ont souvent eu les positions les plus proches de l'APRIL ou de la Quadrature sur ce genre de dossiers. Après, j'aimerais bien savoir si on aurait une nouvelle de cet acabit si le vieux Le Pen mourrait par exemple. Je comprends qu'on veuille mettre en avant Rocard pour tout ce qu'il a fait, mais je ne suis pas sûr qu'on en ferait autant pour n'importe qui avec les mêmes positions. Et c'est un peu ce qui me gêne dans cette dépêche et dans ce concert de louanges libristes.

Ça n'a pas tellement changé en vrai, je pense qu'il y a toujours autant de gens qui trouvent que «c'était mieux à vent» ;)

J'ai voté pour la lecture de code.

Je crois qu'on sous-estime cette activité, notamment dans l'apprentissage de la programmation. Moi, j'adore lire du code, on apprend plein de choses en lisant un bout de code. Mes codes préférés à lire sont les libc (la GNU ou la BSD) et les coreutils, Qt, LLVM, SFML.

Sérieusement, trouverais-tu démocratique 50.0001% des gens qui traitent en esclave 49.9999% des gens? quel lien avec la démocratie?

Ce que tu ne comprends pas, c'est que la démocratie, c'est un processus de décision, ce n'est absolument pas une manière d'établir une certaine morale. Et quand on prend une décision, on peut se tromper, le truc cool c'est qu'on peut toujours prendre une décision contraire un peu plus tard. L'esclavage était légal sous pas mal de démocratie (France, US, etc), ils avaient fait ce choix de manière tout à fait démocratique, même si, de nos jours avec nos standards moraux contemporains, on trouve ça choquant.

La deuxième chose que tu ne comprends pas, c'est qu'une fois la décision prise, ça n'enlève pas les idées des opposants. Dans le cas qui nous intéresse, les partisans du Remain ne vont pas subitement penser que Leave, c'était mieux finalement. En revanche, ils vont se ranger à la décision prise, parce que sinon, si tout le monde décide dans son coin, ça peut vite devenir le bordel. C'est un peu comme si le droit du travail variait d'une entreprise à l'autre, en étant moins favorable que la loi (oups, c'est ça la loi Travail).

ils se débrouillent autrement.

Ils demandent à Siri ?

oui, je sais faire, mais le problème, c'est que quand ce n'est pas quiet, c'est beaucoup trop verbose, il n'y a pas de juste milieu…

En tant qu'utilisateur de base de Debian (depuis potato quand même), j'ai laissé faire l'installation de systemd quand ça s'est présenté. Depuis, bah ça marche pas plus mal que si c'était pire, pas moins bien qu'avant, pas mieux non plus. Il y a quelques détails qui me chagrinent un peu.

Au démarrage, on ne voit plus les logs du kernel et les services qui démarrent. Oui, moi j'aimais bien voir tout ça, notamment les services, parce que des fois, j'installais un truc pour tester et du coup, je voyais le service au démarrage et je me souvenais qu'il fallait que je désinstalle le bouzin. Maintenant, je ne vois plus rien. J'ai essayé de modifier l'affichage de systemd mais là, on voyait beaucoup trop de choses et donc, rien de pertinent. Dans le même ordre d'idée, on ne voit plus la barre de progression de fsck, et comme ça prend un peu des plombes parfois et qu'on a aucun retour, c'est très agaçant. Enfin, il y a tous ces petits trucs à la con du genre la commande halt qui n'arrête plus complètement la machine (il faut utiliser poweroff), et l'attente d'1m30 quand un service récalcitrant (dont on n'aura pas le nom évidemment) ne s'arrête pas correctement.

Bref, je trouve qu'on perd un peu en maîtrise quand on est simple utilisateur observateur de son système comme moi. Il y a beaucoup de choses qui sont cachées. Pour la vitesse, je n'ai pas remarqué que ça allait particulièrement plus vite ou moins vite.

Moi j'avais compris qu'avec SPIR-V, toute la partie optimisation était sorti du pilote et réalisée hors ligne et que, en gros, on n'avait plus qu'à traduire les opcodes SPIR-V dans le dialecte de la carte graphique choisie.

«si on a rien à se reprocher, pourquoi refuser le flicage ?» Merci pour cet argument usé jusqu'à la corde !

est-ce la liberté que de violer la loi? hum… Ca ressemble à des gens oubliant que la liberté des uns commence où s'arrête celle des autres.

Perso, j'avance l'idée de ma liberté de ne pas payer un truc très cher (les pièces c'est cher, en plus qu'on te le file gratos ce qui n'est pas normal, on devrait te facturer ton usage) pour juste toi. Voila, vive la liberté.

Tu as une conception de la liberté qui est très étonnante, très égocentrique : toi tu devrais avoir la liberté de choisir, mais les autres non, suivant comme ça t'arrange en fait.

c'est quand même plus facile de parser un truc binaire bien spécifié et déjà prémâché qu'un texte, non ? Après, oui évidemment, il faudra toujours produire le binaire pour la carte…

SPIR-V n'est pas un langage, c'est une représentation intermédiaire entre les langages de shader (qui ne vont absolument pas disparaître) et le code compilé pour la carte graphique. L'avantage, c'est que c'est plus facile à décoder pour le driver (plus besoin d'embarquer un compilateur !), et en plus, on pourra utiliser d'autres langages (comme C ou C++) qui cibleront SPIR-V. Un avantage pour les logiciels propriétaires, c'est qu'ils peuvent maintenant embarquer un fichier binaire plutôt qu'un fichier texte pour les shaders. Un dernier avantage, c'est qu'il est possible de construire tout un éco-système d'outils autour de SPIR-V (optimiseur, analyseur, etc), et c'est Khronos qui a pris les choses en main en faisant tout en open-source.

Enfin, notons que SPIR-V a été très largement inspiré par la représentation intermédiaire de LLVM.

Le droit d’auteur sauce Linuxfr. C’est tu lances la pièce. Pile ils gagnent face tu perds.

Je viens de découvrir ce soir l'étendu de ton oeuvre et je dois dire que je me suis bien marré. Parce que visiblement, tu ne sais absolument pas de quoi tu parles. Tu te fais une idée de ce qu'est le droit d'auteur (qu'on pourrait résumer à "c'est mon bébé, pas touche") et tu nous fais une joli crise de paranoïa. Et tu sembles ne pas connaître tout un tas d'autres règles juridiques comme celles issues de la LCEN. Mais je dirais que ce qui te manque le plus, ce n'est pas des connaissances de droit, c'est simplement du savoir vivre et de la politesse.

Maintenant, tu peux aussi aller voir ailleurs si on y est, juste comme ça.

Oui, celle-là. Si on transpose, ça donne : plus il y a de Brave, moins il y a de pubs ; moins il y a de pubs, moins il y a de Brave.

Je viens de voir cette infographie sur leur site et je ne sais pas trop quoi en penser pour le coup

C'est totalement contradictoire avec leurs intentions (instant troll mais bon, venant d'un ancien CEO de Mozilla, on ne s'attendait pas à autre chose, fin de l'instant troll), dans le sens où ils annoncent être plus rapide en désactivant les pubs et les trackers, sauf que leur modèle économique est fondé sur les pubs et les trackers. C'est complètement schizophrénique comme situation. Ça tient presque de la blague sur le gruyère et les trous. Et ça ne peut amener que vers des trucs pas nets (en quoi leurs pubs sont-elles mieux que les pubs des autres, outre le fait qu'ils touchent une plus grosse part ? comment sont choisies les pubs affichées ? etc).

Non, ce que j'appelle défaut, c'est un bug, une fuite mémoire, un crash, un trou de sécu, etc.

Tu fais une analogie clairement abusive entre gestion manuelle et bug.

Ma condescendance répond au complexe de supériorité des gens qui pensent que les défauts de gestion mémoire sont forcément dus à l'intervention d'un "mauvais programmeur"…

Tu pars dans un délire paranoïaque. Personne n'a dit que la gestion manuelle de mémoire, c'était le paradis et la facilité et que tous les bugs étaient dû à des mauvais programmeur. Le but de ce fil, c'est juste de dire qu'un GC a un coût en terme de performance, de latence et que ce coût est inacceptable dans beaucoup de domaines.

Postuler des turpitudes individuelles comme cause de tous les problèmes empêche de prendre conscience des effets de système.

D'un autre côté, accuser l'effet de système permet d'exonérer certains programmeurs des mauvaises pratiques connues depuis des décennies qui mènent à des catastrophes. Parce que la solution au «problème», ce n'est pas de dire que tout le monde passe à un langage à GC, c'est d'appliquer les bonnes pratiques, de trouver des pattern d'allocation qui rendent cette tâche simple et sûre. Croire qu'un GC est la solution ultime à tous les problèmes de gestion mémoire, c'est se tromper lourdement.

La proportion d'applications où un GC est hors de question est appelée à diminuer. Comme le rappelle un intervenant, un téléphone "intelligent" aujourd'hui est suffisamment puissant pour faire tourner une JVM entière.

Les domaines pour lesquels un GC est inenvisageable à l'heure actuelle ne risque pas de diminuer parce que, pour la plupart, ce sont des domaines où les performances et/ou la latence sont primordiales et donc, on en revient à ce qu'on disait au début.

Tu dois bien avoir un moyen de connaitre la résolution d’écran et de pouvoir initialiser le jeux en full screen.

Dans l'idée, je préfère laisser le choix à l'utilisateur d'être en fullscreen ou pas. Maintenant, c'est vrai que je pourrais mettre le fullscreen par défaut. Et oui, il y a moyen de connaître la résolution de l'écran avec SFML.

Ensuite tu peux calculer le ratio pour pouvoir afficher ton jeux toujours de la meme façon, surtout pour les dialogues par exemple.

Ça, j'ai déjà une classe qui s'en occupent. Les éléments d'interface ont des tailles fixes quelle que soit la résolution et positionnés de manière relative (par exemple, au milieu).

Ce qui fait avancer le bouzin, c'est qu'il y a peu d'implémentations de GC par rapport au nombre de programmeurs

Et il y a peu d'implémentation de malloc par rapport au nombre de programmeurs.

Certes, rien n'empêche de tout réécrire à la main et de passer des jours à fignoler et débugger ce qui prendrait dix minutes dans un langage haut niveau.

Bel homme de paille. Je n'ai pas dit de tout réécrire, j'ai même dit explicitement d'utiliser une bibliothèque qui le fait. Donc, ça prendra à peu près 10 minutes aussi à écrire.

tu surestimes largement la protection contre les défauts qu'apportent des compétences en programmation bas niveau.

Ce que tu appelles «défaut», ou plus bas «problème», c'est-à-dire la gestion manuelle de la mémoire, d'autre appelle ça un avantage et une force. C'est une question de point de vue, et tu as une manière très condescendante d'expliquer qu'on est tous des gros débiles à vouloir gérer manuellement la mémoire et à vouloir la spécialiser quand c'est nécessaire. C'est ce que font plein de gens tous les jours dans tous un tas de domaines où un GC est hors de question.

Inexact. En fonction de la façon dont ton application alloue et désalloue la mémoire, un GC peut s'avérer plus performant qu'une gestion manuelle. En particulier si tu as des structures profondes (arbres ou listes) que tu modifies peu au cours de leur vie (i.e tu les alloues, tu les utilises sans les modifier, puis tu les désalloues). Dans ce cas, un bon GC pourra tout désallouer d'un coup alors qu'une gestion manuelle t'obligera à désallouer chaque nœud de ta structure.

C'est le genre d'argumentation qui a le don de m'énerver. Un bon GC est meilleure qu'un mauvais programmeur : ho la bonne surprise. Je vais te la faire à l'envers : un mauvais GC est pire qu'un bon programmeur ! Et on a bien fait avancer le bouzin.

Dans le cas très particulier que tu cites «structures profondes (arbres ou listes) que tu modifies peu au cours de leur vie (i.e tu les alloues, tu les utilises sans les modifier, puis tu les désalloues)», déjà ce n'est pas la désallocation qui prendra énormément de temps si ce sont des structures à durée de vie longue, donc chipoter sur le temps de désallocation, je ne comprends pas bien.

Ensuite, rien n'empêche d'utiliser un allocateur spécifique pour ce cas là, genre j'alloue un gros tas de mémoire et je déplace un pointeur pour chaque nœud et quand je veux tout désallouer d'un coup, ben je fais free sur mon gros tas de mémoire. Un programmeur correct sait faire ça assez vite et ça va aussi bien que ton super-GC (voire mieux parce que tous les nœuds seront alloués dans une zone contiguë). Ce genre d'allocateur existe dans beaucoup de bibliothèques.

L'un n'empêche pas l'autre.

Actuellement, j'ai 5 couches de cartes par étage : le fond de carte avec des tuiles (celui dont on parle), une couche basse avec des tuiles (pour mettre par exemple des routes, des petits éléments genre flaque ou cailloux), une couche basse avec des sprites (pour mettre des éléments plus gros qu'une tuile genre un autel), une couche haute avec des tuiles (pour mettre des trucs genre des toits, des plafonds), et une couche haute avec des sprites (pour mettre des arbres par exemple). Le personnage est affiché entre les couches basses et hautes.

Donc, pas vraiment besoin d'avoir des tuiles spécifiques avec des flaques, je pourrai les ajouter où je veux sans aucun problème. Après, il faut juste avoir assez de décors pour que les cartes ne soient pas monotones. Mais même avec ça, je pense que c'est une bonne idée d'avoir des fonds de cartes qui soient variables, même pour un même biome.

J'ai joué un peu avec «Make seamless» et… c'est pas facile ! Ce qui est dur, c'est de trouver la bonne combinaison de paramètres pour que ça rende bien. J'ai essayé avec des photos d'herbe trouvée sur le web et les résultats ne sont pas aussi spectaculaires que dans la dépêche ;)

Sinon, pour mon problème, j'ai eu une idée mais après, je ne sais pas ce que ça vaut. En fait, pour les tuiles autres que celle du centre, il «suffirait» de prendre le morceau correspondant de celle du centre (et donc, on a directement le tuilage), et de faire le raccord avec l'autre morceau sans toucher aux bords.

J'ai un commentaire de plus à propos de «Make seamless».

En fait, si je comprends bien, on peut fabriquer des tuiles. Mais en fait, généralement, on a besoin de tuiles élaborées. Je vais tenter de faire un petit dessin.

      A       B       C    
  +-------+-------+-------+
  |       |   1   |       |
1 |   1   +-------+   1   |
  |     + |   2   | +     |
  +---+---+-------+---+---+
  |   |   |       |   |   |
2 | 1 | 2 |   2   | 2 | 1 |
  |   |   |       |   |   |
  +---+---+-------+---+---+
  |     + |   2   | +     |
3 |   1   +-------+   1   |
  |       |   1   |       |
  +-------+-------+-------+

En fait, on a besoin d'avoir cet ensemble de 8 tuiles avec plein de contraintes : la tuile B2 doit être tuilable avec elle-même mais aussi avec A2 à gauche, C2 à droite, B1 en haut, B3 en bas. Ensuite, la tuile A2 doit être tuilable avec elle-même verticalement mais également avec A1 en haut et A3 en bas. Etc. En prime, les zone 1 et 2 sont des textures différentes (genre du sable et de la pelouse). Et donc, il faut que les tuiles qui contiennent les deux zones rendent plutôt bien et que la transition entre les deux soient clean.

Du coup, ma question : est-ce qu'il serait possible de réaliser cela avec «Make seamless» ? Par exemple, je définis ma tuile B2. Puis, à partir de B2, je fais A2 par exemple en lui disant que ça doit joindre avec B2 et que ça doit être tuilable verticalement. À la fin, je fais les coins avec encore plus de contraintes : par exemple, A3 doit joindre avec A2 et avec B3, mais aussi potentiellement avec une tuile qui ne serait composée que de zone 1 (pas représentée ici).

La gestation est arrivée à son terme ? J'espère pour ta femme que sa phase de travail n'a pas duré aussi longtemps. :-)

Le bébé est arrivé avec 3 jours de retard ! :D

Par contre pour les terrains, la couleur uniforme (vert et marron) ça fait un peu « plat » et ça contraste avec les autres éléments. Ne pourrais tu pas voir avec David Tschumperlé pour faire des textures de terrains avec G'MIC ?

Je suis entièrement d'accord avec toi sur le côté «plat». Ces tuiles sont issues de la génération aléatoire du terrain de l'épisode 11. C'était fait de manière très basique pour l'instant.

En fait, j'aimerais pouvoir générer ou construire un tileset qui soit propre à Akagoria. Et pour ça, j'aimerais avoir beaucoup de tuiles différentes, même pour un même biome, parce que le fond de carte est ce qu'on va voir le plus souvent. Actuellement, quand je me ballade sur la carte, je trouve qu'il n'y a pas assez de variété dans le fond de carte (ça vient aussi du fait que la carte est nue mais quand même).

Utiliser G'MIC est une option très intéressante (et j'y pense depuis un moment) parce qu'il a des effets très intéressants, et parce qu'il a un langage qui permet de manipuler les images et donc de scripter éventuellement la génération des tuiles.

Le pire, c'est que si je me bougeais, je pourrai le sortir la semaine prochaine le E17 !