rewind a écrit 3434 commentaires

Je suis pas d'accord avec ça. Tu peut vouloir gérer plus de choses. Le poids et la forme peuvent très bien évoluer, c'est justement ce que tu expliquait l'an dernier avec les balles qui acceptent des inputs. Tu crée des contraintes avec ces données statiques (qui peuvent potentiellement nuire à l'évolution du jeu).

J'aurais dû dire «sont des données statiques pour l'instant». Mais tu as entièrement raison. Le truc, c'est de savoir ce qui va évoluer au cours du jeu ou pas. Si ça bouge, alors on le met dans un composant, sinon c'est une donnée statique. Et une donnée peut passer d'une catégorie à l'autre et dans ce cas, il faut modifier le ou les composants adéquats.

Oui, c'est un peu l'idée que j'avais en tête. Mais ce n'est parfois pas si simple. L'exemple que j'ai en tête et qui m'a causé beaucoup de souci, c'est la carte. C'est typiquement un truc statique donc chargé à part. Mais elle a des interactions avec des entités, par exemple pour les collisions. Un arbre sur la carte, il n'a pas d'état dans le jeu mais il a un corps qui apparaît dans le moteur physique. De même, le fond de carte. Au début, j'avais une entité pour chaque tuile et du coup, j'affichais tout avec le système en charge de l'affichage. Grosse erreur ! Les tuiles ne font pas partie de l'état du jeu ! Mais il faut quand même bien les afficher. Donc c'est le système en charge de l'affichage qui affiche la carte, puis toutes les entités qui ont le composant qui va bien pour être affichées, comme le héros par exemple. Et dans le cas du héros, le sprite fait bien partie de l'état du jeu, parce qu'il peut changer en fonction de l'animation. Bref, quand je dis que la frontière est floue entre les deux, je parle de ça.

Si, mais il faudrait le faire pour tous les composants, et même pour chaque champs de chaque composant. Ou alors, il faut mettre cette logique dans la fonction de sauvegarde qui pourrait avoir cette information mais ça complexifie la sauvegarde. On passe d'un truc simple comme ça :

pour tous les types de composants
    pour tous les composants de ce type
        sérialiser composant
    fin
fin

Et pour le chargement :

pour tous les types de composants
    pour toutes les sauvegardes pour ce type
        désérialiser sauvegarde
    fin
fin

À un truc complexe comme ça :

pour tous les types de composants
    si le composant ne doit pas être sauvegardé alors continuer
    pour tous les composants de ce type
        pour chaque champs
            si le champs ne doit pas être sauvegardé alors continuer
            sérialiser champs
    fin
fin

Et la sauvegarde devient aussi plus sportive parce que, pour les champs non-sérialisés, il faut savoir comment les initialiser, et pour les composants non sérialisés, il faut les recréer à partir d'une autre source. Du coup, la procédure est plus complexe, à mon sens.

Justement j'ai une question sur les systèmes à entité. Je pense avoir bien compris le découpage système/entité/composants, mais je me demande comment faire des systèmes multi-entités. Pour du jeu vidéo c'est par exemple comment limiter le nombre d'unités ou gérer des collisions. Est-ce qu'il faut créer des composants qui pointent sur des entités (par exemple une entité stat qui connaît la liste des entités unités) ?

Alors, je ne suis pas sûr de bien comprendre la question, mais je vais essayer de répondre.

Si la question est : est-ce qu'une entité peut «pointer» vers d'autres entités, la réponse est oui. Comme exemple, on peut imaginer une entité «Besace du guerrier» qui a un composant Container qui contient un tableau d'entités (le contenu de la besace). C'est comme avec des pointeurs sauf qu'on utilise ici les entités qui ne sont que de simples identifiants. L'avantage, c'est que ça se sérialise très bien.

Après, pour les collisions par exemple, c'est un peu plus complexe, et ça ramène à la discussion du dessus. Dans l'idéal, le système qui gère les collisions n'a pas besoin de pointer sur les entités directement, il peut être assez autonome. Pourquoi ? Parce que l'état d'une entité par rapport aux collisions, c'est sa position et sa vitesse. En particulier, toutes les données physiques (formes, caractéristiques) sont des données statiques. Quand on modifie la vitesse (ou la position), on prévient le moteur physique, puis au moment où le système qui contient le moteur physique se met à jour, il fait sa petite simulation. Et à la fin, on met à jour les positions et les vitesses de toutes les entités. C'est une vision simplifiée mais ça donne une idée. Le moteur physique fait ses simulations dans son coin et le système se charge de faire la passerelle entre les entités et le moteur physique.

Nous sommes bien d'accord : le problème, c'est bien la sauvegarde. Dans un système à entités, normalement, tu sauvegardes tous tes composants, de manière à retrouver exactement ce que tu avais quand tu as sauvegardé. Les données statiques, pour moi, elles doivent être à part, parce qu'on ne va pas les charger de la même manière ni depuis la même source. Mélanger les deux comporte le risque de complexifier la sauvegarde, ce qui serait un comble vu que c'est un des avantages des systèmes à entités.

Mais je comprends bien ton point de vue, et je mesure la difficulté de tout séparer.

Si des complotistes renommés en parle, c'est que ça doit être vrai…

Là il y a tout de même un point notable : la guerre en question n'a pas été commencée par l'Occident, et et nos pays se coordonnent pour aider les agressés. C'est à dire, les populations agressées, parce qu'on peut difficilement parler de pays agressés dans la mesure où il s'agit en partie d'une guerre civile. C'est très, très différent d'aller attaquer un pays étranger tout de même.

L'Etat Islamique, c'est le résultat de toutes les guerres menés dans la région et pas loin depuis des décennies (Irak, Afghanistan, Syrie, Lybie). Ils ont toutes les armes qu'on a donné aux différents camps qu'on soutenait puis en fait non. Pour quel résultat ? Toujours plus de merde. On va s'arrêter quand ? La guerre n'est jamais une solution.

De plus, l'armée que l'on cherche à attaquer, à savoir les combattants de l'“État” islamique, est coupable d'actes de barbarie et de ce qu'on qualifie de crimes contre l'humanité, il est donc bon d'agir pour qu'ils cessent et pour qu'ils répondent de leurs actes devant la justice. Le tout est d'agir pour cela sans faire encore plus de dégâts.

Quand on voit tous les Etats qui ne reconnaissent pas le TPI, je me demande bien par quelle justice ils vont être traité.

Pour prendre une comparaison, deux guerres mondiales ont été terminées par une intervention des États-Unis, intervention certes guerrière puisqu'on était en guerre, mais tout à fait louable, et sans laquelle la merde dans laquelle on était aurait continué.

La propagande atlantiste fonctionne bien. Ce qui a permis la fin de la guerre (la 2è), c'est avant tout l'avancée de l'URSS sur le front de l'est. C'est ce qui a décidé les Etats-Unis à venir en Europe, pour ne pas la laisser aux mains de ces sales communistes, faut pas déconner. Il suffit de voir le nombre de morts et la chronologie pour le comprendre. Mais de nos jours, on ne parle même plus de l'Armée Rouge quand on évoque cette deuxième guerre mondiale.

«algorythmique», ça pique un peu les yeux (dans «Formation Game Design et Programming» dans le programme). Et de manière générale, le site ne rend pas bien du tout sur mon Chromium, certains items du menu bavent sur la ligne suivante. C'est dommage pour une formation au web design.

Je me réponds à moi-même : ils y pensent (mais c'est encore à un stade très précoce apparemment)

Est-ce qu'il est prévu dans PHP7 d'harmoniser les noms (et le comportement) des fonctions de la bibliothèque standard ?

Il n'y a pas de fonction supprimer ?

Je suis d'accord sur le principe avec ta remarque. Mais force est de constater que les brevets d'aujourd'hui sont incompréhensibles et ne permettent pas de reproduire correctement le procédé du brevet. Il y a plus de charabia juridique que de données techniques maintenant. C'est un problème.

De nos jours, je pense que la loi pourrait imposer de lever le secret industriel dans certains secteurs, avec les mêmes arguments que pour l'OpenData, à savoir que ça devient un impératif démocratique de savoir précisément ce qu'on nous vend, histoire de ne pas avoir de surprise après.

Depuis C++11, il y a même de telle variables dans la bibliothèque standard.

Moi je n'ai pas trouvé cet entretien si bon que ça. Il y a quelques bons passages sur son expérience, mais c'est noyé au milieu d'une compilation de ses trolls préférés qui sont déjà saoulant quand on les lit dans des commentaires. C'est dommage de profiter d'une interview de ce genre pour ramener sur le tapis tous les poncifs qu'il nous sort sans arrêt. L'entretien aurait pu être plus intéressant sans ça et avec d'autres questions, comme par exemple quel genre de services attendent les entreprises dans ce secteur, quels sont ses concurrents, etc. Bref, sans doute quelque chose de plus professionnel, plus de Martinez et de moins Zenitram.

malheureusement, vu qu’un partie des personnes se disant libristes s’amusent toujours à opposer une supposée pureté d’un tout libre non commercial fantasmé au commercial ou à la cohabitation avec le non-libre, il a des peurs sur le libre à enlever, c’est un travail long

Troisième question, on l'a déjà reconnu…

je suis assez individualiste

Sans déconner !

J’ai essayé de mettre un maximum de trolls dans mes réponses, spécialement pour LinuxFr, lequel prendra le plus ? :-D

Ça va, j'ai eu bon ?

Oui, ce qui m'étonne, c'est que pour un problème de l'espace utilisateur, on propose une solution du noyau. Parce que là, ça revient à se lier à un système de fichier, c'est très embêtant. Je pense qu'on pourrait faire le même genre de chose avec git, sans souci (une branche par config) puisque git a été conçu au départ par Linus comme un système de fichiers.

Une solution qui ne décolle pas, c'est une solution ratée.

Ça dépend, si tu l'imposes… (koff koff… systemd… koff koff)</troll>

Et parfois, ça coince, comme par exemple pour les vector<vector<int> > qui ne compilent pas sans le disgracieux espace entre les deux >.

Et bien bonne nouvelle, depuis C++11, on peut écrire vector<vector<int>> et ça compile gracieusement !

le _ fait partie du nom, donc on pourrait très bien avoir un user defined literal qui serait _42, c'est là qu'est l’ambiguïté (qui ne peut se résoudre qu'à un niveau sémantique).

Non, ça ne pose pas tant de problème que ça parce que dans le deuxième cas, tu ne peux pas avoir de quotes au début alors que pour un caractère, il doit obligatoirement apparaître au début (c'est un peu le même genre d'argument que pour le x dans les nombres hexadécimaux).

Oui, je crois que c'est à cause des litéraux définis par l'utilisateur (les trucs qu'on ajoute derrière un litéral pour préciser son type, comme 1L ou 0.1f). Dans la norme, il est dit que ceux qui ne font pas partie de la bibliothèque standard doivent être préfixés par _ (comme 1_km) et du coup, si le choix avait été fait sur _, ça aurait été un peu perturbant, sans compter que ça aurait complexifié le parsing (on tombe sur _, est-ce un séparateur de chiffre où le début d'un suffixe de litéral ?).

Alors, je reprends : oui pour certains, ça vaut la peine. Mais ça ne devrait pas valoir la peine parce que, selon moi, le salaire devrait être le même. Je ne vois pas en quoi j'extrapole quoi que ce soit.

Tu m'expliques où est-ce que tu as vu que les français ne voulaient plus de leur administration à cause du mode de rémunération ? Tu fumes ou quoi ? C'est dans ta tête ça, uniquement. La réalité me donne plutôt entièrement raison pour l'instant. Ce que tu appelles réalité, c'est ce que toi tu aimerais imposer aux autres parce que tu penses que c'est mieux, mais je t'assure que tu prends ton cas pour une généralité. Et puis, si c'est tellement le bonheur ultime d'être fonctionnaire, je t'en prie, passe un concours (ben quoi, tu nous la fais bien pour patron régulièrement, alors pourquoi pas hein).

Donc quelqu'un qui fait le même job mais mieux n'est pas augmenté ?

Si, comme je l'ai expliqué, il peut demander un avancement et donc être augmenté plus vite que son voisin. Mais il faut lire la phrase en entier.

Donc, c'est bien un moyen très mauvais d'évaluer les compétences et donc le salaire qui en découle.*

Absolument pas. Tu as un ensemble de compétences à satisfaire pour un poste. Le concours permet de savoir qui satisfait cet ensemble de compétences, rien d'autre.

Le problème, c'est que tu vois le problème de manière individualiste, alors que la fonction publique voit son problème de manière globale (sans compter qu'il faut assurer des critères permettant de ne pas remettre en cause les fonctionnaires recrutés).

Mais dans les cas où les candidats se trouvent en abondance, bien entendu que l'employeur décide car il a le choix. Et alors ? Tu veux éviter ce phénomène comment exactement ?

La question initiale, c'est de savoir si, à compétences égales, on doit avoir un salaire égal ou si, comme c'est le cas pour les logiciels libres, on doit accepter de baisser son salaire parce que c'est cool les logiciels libres (en tout cas, pour l'employeur). Donc, ça ne remet pas en cause la capacité de choix de l'employeur parmi plusieurs candidats si c'est ta question.