Creak a écrit 43 commentaires

Ce que j'attendais le plus de C++17, c'était les modules.

Il faut absolument sortir du langage les commandes préprocesseurs. Aujourd'hui, il est impossible de faire un logiciel en C++ sans utiliser la commande #include. C'est pas normal qu'un langage doive s'appuyer sur un autre pour fonctionner.

Personnellement je préfèrerais que le compte linuxfr_officieux partage uniquement les dépêches.

Dépêches, journaux et forums, ça fait beaucoup trop dans mon flux, et surtout trop d'inutile à mon goût. Du coup je ne suis que #linux-depeche.

Mais en tout cas, merci pour ce flux, LinuxFr fait parti des grands absents dans G+ et D*, tu viens de rendre D* bien plus intéressant :D

Je suis aussi assez vieux (par rapport à Internet) et ma réponse c'est tout simplement que je n'ai jamais réussi à accrocher aux RSS. Je sais ce qu'est un flux RSS (et même un flux Atom), je suis plutôt un geek, mais aujourd'hui je trouve que l'organisation et le partage de mes infos sont plus simple avec mes réseaux sociaux (G+ et D*, je n'ai pas FB).

Le RSS, je trouve ça un peu… vieux, en fait.

Je suis pas sûr qu'on ait les même définitions, mais pour moi, un système à entité est le fait de déterminer un objet de base (l'entité) et d'y plugger des fonctionnalités (composants). Et le fait d'être data-driven est le fait que les règles ne soient pas hardcodées; elles sont exposées dans des data éditables par des non-développeurs qui permet de contrôler le jeu.

Par exemple, l'entité est juste un objet-identifiant. On y ajoute quelques composants: une position et une jauge de vie, et on obtient un objet-joueur. Tu rajoutes à ça une IA et tu obtiens un objet-NPC (c'est volontairement simple, évidemment dans un vrai jeu il y aurait bien plus de composants par entité).

D'un autre côté, tu as des data qui sont liés à ses composants, permettant de déterminer différentes spécificités comme les points de vie par exemple. L'avantage c'est que la gestion de la vie c'est le composant qui s'en charge, mais la quantité de vie, c'est les data qui déterminent ça. On peut ainsi mettre différentes data sur le même pattern "entité-composants" et tu obtiens différents NPCs.

Au final, ça permet de bien séparer les systèmes et les data, le contenant et le contenu.

Tu peux aussi utiliser des Pool pour ce genre de cas, comme ça tu continues d'utiliser des pointeurs dans tes vecteurs, mais le Pool permet de s'assurer que les objets sont dans la même zone mémoire.

Par contre, tu as toujours un risque plus élevé de cache miss (par rapport à un vecteur de non-pointeurs) car même si le pool rassemble tes objets dans la même zone mémoire, ils sont proches, mais pas contigus.

Je ne parlais pas de data-driven dans le sens de programmation orientée donnée, mais de data driven dans le sens où c'est la data (des informations hors code) qui dirige le jeu. Par exemple les règles de game design (points de vie des ennemies, type d'IA à utiliser, …) sont dans des fichiers JSON accessible par les game designers. L'un des avantages de la modélisation Entitées-Composants c'est que tu peux facilement lier une telle donnée à un composant.

Ceci dit, la programmation orientée donnée n'est pas exclusif et il est très important de penser au coût mémoire qu'aura tel ou tel algorithme. Cependant une autre règle intéressante à garder en tête est de ne pas commencer à optimiser tant qu'on n'a pas fait de profiling. Il faut toujours optimiser ce que l'on voit dans un profiling. Sinon on peut passer une semaine à optimiser un bout de code qui n'est finalement appelé qu'une seule fois par trame alors que de l'autre coté on a une fonction qui est appelée 100 fois par trame et qui mériterait bien plus d'amour.

Un truc que j'ai remarqué en game dev (mais je pense que ça s'applique au dev de manière général), c'est qu'on a toujours tendance à penser que l'herbe est plus verte ailleurs. Mais il faut se rendre à l'évidence, il n'y a pas de système parfait et il faut faire au mieux avec ce qu'on a. Bien évidemment, il faut optimiser les systèmes aussi, mais ça, ça arrive plus tard, quand tu peux commencer à profiler ton code et donc à détecter les bottlenecks.

Tout ça pour dire que je pense que tu peux aller loin avec un système à entités. Je dirais qu'un gros avantage de ce système, c'est qu'on peut facilement le rendre data driven. Et ça c'est très très important quand on fait un jeu avec une équipe de plusieurs centaines de personnes incluant des non-dev.

Conceptuellement, les systèmes à entités, c'est vraiment satisfaisant. Dans la pratique, c'est très compliqué.

Tu serais surpris de savoir les jeux AAA qui sont fait avec un système à entités. Je ne peux rien dire, mais en tout cas je ne découragerais pas les devs de pousser un peu plus loin le test ;)

C'est vrai, je donne chaque mois à 4 artistes sur Patreon (fondé par un artiste de génie: Jack Conte) et 2 artistes sur Tipeee (version française de Patreon, dérivée de MyMajorCompany). C'est un moyen plus constant d'avoir de l'argent, tout en étant crowdfundé.

Après, rien n'empêche d'avoir les deux (je pense). Tout comme le fait que les youtubers que je sponsorise se font quand même de l'argent avec la pub de Youtube.

Ça m'étonne que personne n'ait encore mentionné Framagit comme alternative libre pour héberger son projet.

En effet, c'est important de marquer cette différence. Au boulot on parle souvent de "stakeholders" en parlant des personnes qui ont un intérêts dans le projet, cela comprend les clients finaux, mais pas que. Il y a aussi les différents leads au-dessus de ton équipe qui ont une vision plus long terme pour le projet.

En gros, un "stakeholder", c'est le mec qui peut te demander "what's in stake?" (i.e. "quels sont les enjeux?")

De ce que j'ai compris, Diaspora* v0.5 a été retardé de plusieurs semaines justement pour tenter de finaliser l'implémentation du XMPP, mais le retard étant trop important, ils ont préféré sortir une version (avec déjà pas mal d'autres fonctionnalité) et avec le XMPP, mais désactivé par défaut car encore expérimental. Peut-être que la prochaine version l'aura?

@Olivier: J'essaye de trouver des informations sur l'existence d'un dictionnaire grammatical pour l'Anglais. Est-ce qu'il existe? Si non, est-il prévu?

Merci!

Ça à l'air vraiment prometteur neovim. Le fait qu'ils pensent activer par défaut des features de bases, comme la souris ou les flèches du clavier, montrent qu'ils ne sont pas trop à cheval sur les "standards" des barbus ;)

En parlant de ça, vous avez réussi à faire marcher un pad PS4 en BlueTooth sur votre Linux? Si oui, vous pourriez me dire comment?

La dernière fois que j'ai essayé (malgré le fait que c'était sensé être compatible), ça ne marchait ni en USB, ni en BT.

J'ai demandé aux devs de Mesa et apparemment si c'est rouge ce n'est pas que parce que c'est impossible à faire, ça peut aussi être parce que le r300 ne l'a pas encore implémenté (les cartes du r300 devenant sûrement vieille, peut-être qu'il y a moins de devs pour ce pilote).

Je me disais aussi que c'était surprenant que R300 était aussi rouge…
Je vais voir ce que je peux faire, mais je vois pas de façon automatique de lier les infos de ces deux pages. À investiguer!

Et je viens de rajouter la séparation par vendeur (Software, Intel, nVidia, AMD) + une colorisation.

J'ai rajouté un petit espace entre la colonne mesa et les pilotes, c'est une première étape vers une meilleure compréhension.
J'ai aussi corrigé quelques bogues et rendu le tout valide avec HTML5.

Si vous avez des idées, n'hésitez pas!
Elles ne seront peut-être pas toutes réalisables, mais je tenterai de faire de mon mieux! ;)

Je me corrige, c'est Eric Anholt, quand il travaillait encore chez Intel, qui a amené ce projet sur la table. Mais il ne s'était préoccupé que de la partie DRI (pas Gallium). Et c'est Emil Velikov qui a finalisé le projet sur la partie Gallium.

J'ai pu retrouvé l'article Phoronix où j'avais lu ça, par contre ça semble être Marek Olšák qui a fait le patch:
http://www.phoronix.com/scan.php?page=news_item&px=MTY5MTA

Je crois que Mesa ne s'occupe que de OpenGL à partir de la version 3.0.
De toute façon les versions précédentes sont tellement différentes/désuettes à écrire… Maintenant les shaders c'est la base d'un moteur 3D, c'est pas une extension ;)

Enfin je dis peut-être des conneries, mais c'est en tout cas ce que j'ai compris! ;)

Ouaip, j'avais vu cette page (après avoir fait mon script d'ailleurs). Elle offre une vision plus pragmatique des évolutions en testant directement sur la compatibilité avec des GPU bien précis.

C'est pas con de faire un lien vers la doc pour chaque extensions, faudrait que je vois comment faire ça.

Ah vi c'est ça! C'est Mega, pas Big!
Si ça concerne tous les pilotes, ça fait un peu peur… Est-ce que ça ne risque pas de nuire à la maintenabilité du code? On se souvient tous de XFree86 qui était un énorme bloc monolithique imbitable (bon, Xorg, c'est mieux, mais y a du boulot encore ;)).

Je me disais aussi que ton nom me disait quelque chose! ;)

Être mis à jour, c'est aussi le but des articles Wikipedia, surtout pour des trucs qui bougent aussi vite que l'informatique ;)
À la base, c'est moi qui avait lancé cet article et il a été très très largement amélioré par Antistress (qui devrait lire ces colonnes normalement ;)).

Si tu t'y connais bien sur la pile graphique, je t'invite à améliorer l'article Wikipedia, ça intéressera toujours du monde (moi le premier!).