rewind a écrit 3416 commentaires

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 !

Merci ! J'avais les mêmes matrices, tout va bien :)

[pas répondu au bon endroit, pardon aux familles]

Voilà, pas mieux ;)

class BabyManager {
public:
  bool isHungry() const;
  void eat();

  bool isDirty() const;
  void changeDiaper();

  bool isTired() const;
  void sleep();
};

En fait, ces nouvelles, ça donne plein d'idées ! Genre là, je me vois bien aller photographier une pelouse, puis appliquer un petit coup de Brushify pour faire comme si je l'avais dessiné, puis un petit coup de Make Seamless pour faire que ce soit une tuile et hop j'ai une belle texture. Bon, en vrai, ça ne doit pas être aussi simple mais je pense que j'essaierai. On peut faire ça avec de la terre aussi et avec tout un tas de choses.

Dans un autre registre, il se trouve que je me suis intéressé au daltonisme récemment, et voir comment rendre une image comme un daltonien la verrait. Du coup, en voyant ça dans la nouvelle, je me suis dit que j'allais voir comment c'était fait dans G'MIC mais je n'ai pas réussi à trouver le bout de code… De mon côté, j'étais également tombé sur le site mis en lien mais j'ai eu du mal à trouver des références avec des choses précises. Et puis, je suis tombé sur des bibliothèques javascript qui faisait exactement ce que je voulais (mot-clef: color matrix) et finalement, c'est très facile.

Ça marche pour un public technique (et ça demande à avoir un serveur en permanence,

Comme une box ? ;)

on n'en est qu'au début, ça met du temps à décoller, et cela a l'air complexe et lourd

Franchement, je trouve que ça résume bien l'état (permanent) de XMPP. On n'a pas l'impression d'un projet mature qui construit sur des bases solides, mais plutôt d'un truc qui se renouvelle en permanence sans jamais avancer réellement et donc, en est toujours au début. Sans même parler du complexe et lourd dans le choix des bons couples clients/serveurs.

Ceci dit, j'ai trouvé un peu cavalier de passer sur IRC aussi rapidement. Parce qu'avec IRC, on a toujours trouvé des solutions pour tout le bazar qui est maintenant intégré. La présence permanente était réglé depuis bien longtemps par tout un tas de gens avec un irssi dans un screen sur un serveur connecté en permanence. Oui c'est austère mais ça marche, ça utilise des trucs existants qu'on assemble pour avoir une fonctionnalité avancée, dans la bonne tradition Unix. La dépêche semble louer l'intégration maximum des fonctionnalités. Certes, pour l'utilisateur lambda, c'est sans doute une bonne idée, mais ça ne veut pas dire que c'est vraiment nouveau. Et je passe sur le fait que toutes ces technos à la mode se font sur des protocoles bien propriétaires. Et personnellement, je ne crois pas que XMPP parviendra à être le protocole ouvert qui égalera ces applications.

«156 km/h, c'est la vitesse à laquelle tout le monde devrait rouler pour que les motards n'ait pas à doubler comme des gros sales entre deux files» ?

Ha mais je pense au contraire que je le comprends trop bien ! Tu as esquivé le principal reproche qui est fait, tu t'es auto-caricaturé dans ton rôle de motard qui se fout du code de la route et qui pense que ça ne s'applique pas à lui. Exactement ce que dit le journal finalement.