Tout ce qui passe par la mémoire du processus !
Je ne connais pas assez l'architecture des serveurs web, mais est ce que, par exemple, apache, fait tounrer dans le même process, la compilation du php, leservicede page web et le protecole de communication, en particulier les algos de chiffrement ?
Tout ce qui est exécuté dans des processus séparés devrait à priori ne pas devoir être impacté, non ?
L'installation de ton paquet n'écrit pas forcément directement dans ton home, mais l'utilisation du logiciel installé y sauvegarde généralement ses préférences.
Et il arrive que le format change et devienne incompatible avec une ancienne version.
si tu arrive avec ton code imbitable généré par lex et que par magie tu arrive à le faire accepter
Je n'arrive pas avec du code imbitable généré par lex. J'arrive avec un fichier lex lisible qui est compilé pendant la phase de compilation.
"Bonjour, j'ai ré-écrit le gros pathé de code imbitable en une série de strcmp(), J'ai économisé 3 Kio de taille de binaire en x86, et en plus j'enlève 50 lignes de code"
Il n'aura rien ré-écrit du tout car ce "pathé de code imbitable" n'est pas écrit. Encore une fois, c'est un fichier lex simple, très lisible (pour peu que l'on conaisse la syntaxe, comme tout format de fichiers) et sincèrement très compliqué à battre, tant en terme de performance que de consomation mémoire (bon, peut-être pas en consomation, mais c'est pas la mort non plus)
Inventer une soupe contextuelle et sortir ton lex/yacc en bloatant ton système de build est juste inacceptable.
Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format, et quand j'ai à analyser cela, je crée un analiser lexical avec lex que je couble avec un petit switch. Tu as remarqué que dans mon post original, je prenais soin de mentionner que je ne couplais en aucun cas ça avec du yacc/bison.
Encore une fois, si j'ai 3 mots clés que je lis 2 fois chacuns, je ne le fais pas. Quand cela commence à gonfler, c'est le tas de if/else avec des comparaisons de chaines qui deviens du bloat.
Le plus simple restant encore de ne pas écrire de grammaire soi-même et d'utiliser des parseurs que d'autres ont écrits.
Une fois encore, je n'écris pas de grammaire !! juste un automate à état finis généré par lex que je couple avec un switch en C
Après si c'est lex qui te donne des boutons, tu n'as qu'à l'écrire à la main ton automate, mais tu seras moins bon que lui et quand ce que tu auras à parser change, il faudra le réécrire, c'est pas terrible.
C'est la meme personne, mais il y a une raison pour utiliser memcmp et pas strcmp dans ce cas la. Ca permet de ne regarder que les 2 premiers caracteres.
Au passage, je sais que git n'est pas un composant critique en terme de sécurité, mais ça ne coutait pas grand chose de mettre des strNcmp.
D'ailleurs, il y en a un au milieu qui est un memcmp, ça ne doit pas être la même personne qui l'a écrit, celui là :)
Ça marche quand tu en as un nombre assez faible et que tu n'as pas besoin de performances importantes.
Dans ce cas là oui, je trouve même que c'est plus lisible de la sorte.
Mais j'ai un peu de mal à appeler cela un parser (ou un analyseur lexical)
Mais si tu dois passer à la moulinette de plus gros fichiers, que tu as beaucoup de mots clés à y reperer et qui peuvent revenir souvent (et c'est le cas pour des fichiers de configuration), je pense qu'utiliser flex (sans l'associer à bison) et plus efficace et maintenable (ajout de nouveaux mots clés, de patterns, …)
Ou sinon tu fais au moins un vrai test avant de sortir le produit, et tu évite les changements après le début de la phase de test, on est en phase de dévelopement/debogague là.
Si tu ne testes même pas le menu de base avant la sortie de ton produit, j'ai de fort doutes sur sa qualité globale, même s'il est écrit avec un super algo de la mort qui tue.
tu utilises un fichier texte pour stocker la config, comme ça tu leurs explique comment faire ça et ils se débrouillent !
Tu verras qu'ils auront tout de suite moins envie de tout changer toutes les 5 minutes :)
Et une fois encore, c'est u menu, s'il y a 4 entrée, c'est pas trop la mort d'écrire un truc du genre (très verbeux pour l'exemple, on peut faire beaucoup mieux)
menu "Nouveau Jeux" {
precedent rien
suivant "Charger une savegarde"
}
menu "Charger une savegarde" {
precedent "Nouveau Jeux"
suivant "Options"
}
menu "Options" {
precedent "Charger une savegarde"
suivant rien
}
c'est franchement pas la mort, et même si ça change souvent, ça reste simple a décrire et même un designer peut le faire !
Je suis globalement d'accord, à moins que la position de tes menus ne soit choisi aléatoirement à chaque fois que tu lances ton application, elle est figée une fois pour toute, c'est de l'aléatoire, mais pas trop (http://xkcd.com/221/)
donc une fois que les artistes se sont mis d'accord sur la position des menus, tu décide de l'ordre de navigation et tu le codes en dur.
En fait, j'aurais pu mieux l'expliquer en montrant plusieurs octaves consécutives. Il existe des exemples en 1D pour bien comprendre, genre là (et d'ailleurs, j'ai oublié de mettre ce lien qui explique bien les choses, de manière très visuelle).
Ce lien est parfait, merci :)
Je pense que cela vaut le coup d'éditer la dépêche pour le rajouter !
Heu, il est défini le point P, sur une des images insérées dans le texte, dans la section du bruit à base de valeur. Le point P et le point A se refère à cette image là, pas à la présentation de Perlin. Je n'ai pas les mêmes notations que la présentation de Perlin d'ailleurs, j'ai simplifié.
Oups, je n'étais pas remonté jusque là !
Et du coup, ma tentative d'explication est fausse par rapport à ta notation !
Dans ce cas, ce qui m'a induit en erreur est la début de la phrase : "Pour le point A"
J'ai vraiment pensé qu'il s'agissait d'un point final pour lequel on veut une valeur d'altitude.
Salut, j'ai trouvé ton article très intéressant et instructif !
Tu m'as donné envie de recoder des trucs (oui je sais, je dis ça un article sur deux dans ta série de dévelopement de jeux vidéo… mais là promis, j'y crois :))
Juste queslques précision sur des points que j'ai eu un peu de mal à comprendre :
Elle consiste, à partir d'une fonction de bruit «simple» à combiner plusieurs octaves de différentes amplitudes et de différentes fréquences. Plus précisément, pour chaque octave supplémentaire, on divise par deux l'amplitude, on multiplie par deux la fréquence, et on additionne toutes ces octaves.
Sans lire le papier "terrain generation" sur lequel tu mets un lien en début d'article, c'était complètement obscur et incompréhensible pour moi.
Qu'est ce qu'une octave ?
À quoi corresponds l'amplutide ? la fréquence ?
Après l'avoir lu, j'ai compris, et je ne suis pas sur de savoir mieux l'expliquer, mais peut etre rapprocher cette phrase du lien ou donner un exemple simple avec 2 ou 3 (ça risque d'être trop long) octaves, en détaillant complètement l'algo et les calculs, pourrait aider.
Pour le point A, on calcule le produit scalaire entre le gradient défini au point A et le vecteur PA. Et pareil pour les trois autres. Enfin, on interpole ces quatre valeurs comme pour le bruit à base de valeurs.
le point P n'étant pas défini, j'ai cru au début à une faute de frappe de ta part, j'ai compris ensuite que je n'avais pas compris ;)
Mais je pense que cette partie mérite aussi une explication supplémentaire.
Comme par exemple définir les 4 (ou n, pour un hypercube) points Pi autour de A et Gi le gradient en Pi. Enfin, poser le produit scalaire Gi.(Pi-A) comme dans le papier de Perlin (c'est une suggestion de présentation, bien sur, mais moi ça m'aurait aidé à comprendre beaucoup plus vite)
Sinon c'est vraiment chouette :)
Je n'ai pas encore approfondi la partie ombres, mais elle m'intéresse aussi.
Je vais peut-être reprendre (dès que le soleil repartira…) le code de génération de terrain aléatoire que j'avais tenté décrire en vains lorsque j'étais étudiant.
la technique que j'avais imaginé à l'époque, et qui ne marchait pas du tout, fonctionnait "dans l'autre sens" de ce que tu décris ici, à savoir créer une map aléatoire, et appliquer des filtres de moyenne et de lissage pour obtenir un résultat.
Le problème est que pour avoir quelques chose de correct, il faut faire beaucoup d'itérations, et du coup la carte se retrouvait avec un relief très faible.
Et lorsque j'ai tenté de baisser la fréquence de map carte aléatoire de départ, je voyais clairement apparaitre des artéfact carrés dans mon résultat.
Il faut dire aussi que mes techniques de lissage étaient basé sur des moyennes polynomiales (linéaires ou quadratiques pour la plupart), pas du tout adaptées :)
Pour les ombres, comme je faisais du rendu 3d (avec OpenGL), je n'avais pas de soucis particuliers.
Oui, mais après faut accepter d'avoir des boîtes noires dans son OS
Non, si tu n'en veux pas, ne les utilise pas, ça ne change rien à ta façon d'utiliser ton OS aujourd'hui !
L'auteur du journal à l'air de n'avoir pas de soucis particuliers avec ce point et accepte la boite noire, donc pas de soucis.
Au passage, si tu veux quand même utiliser ce genre de logiciel mais que le coté boite noire te gêne, il y a une solution intermédiaire qui serait de créer un utilisateur "jeux" qui ne sert qu'à cela, ça n'est pas la panacée et tu t'expose toujours au des attaques sur des failles de type escalade de privilège, cassage des mots de passe des autres utilisateurs par brute force, mais c'est toujours un peu mieux pour te protéger des techniques simple de tracking et d'espionnage de ta vie privée que de tout avoir sous le même compte.
ce serait d'avoir des jeux plus performants / plus jolis sous linux, voir de belles exclus
Perso, je suis un peu comme beaucoup de monde ici (à en lire les commentaires, je me trompe peut-être) et le fait qu'il y ait plus de parts de marché ne m'intéresse que dans la perspective que pour de logiciels soient portés et maintenus, que les pilotes soient de meilleur qualités, les périfériques tous supportés, …
Mais des parts de marché pour des parts de marché, je m'en fou un peu.
Et le fait que des personnes y passeraient pour des exclus ne me réjouis pas spécialement.
D'ailleurs je trouve cela con qu'il y ait des exclus. Qu'il y en ait parce que les gens développent dessus et n'aient pas le temps, les compétences pour porter les logiciel ailleurs, ça me parait normal et logique, mais que cela soit une exclus juste pour dire "on a la plus grosse" je trouve cela con.
"notre OS préféré" ???
Moi, c'est mon os préféré parce que je fais ce que j'en veux !
Parce que l'os ne me mets pas de bâtons dans les roues volontairement pour me limiter ou décide à ma place ce que est le mieux pour moi sans me laisser d'alternative.
Parce que je le trouve plus performant, pratique et simple d'utilisation (oui oui) que les autres.
Et aussi pour son coté communautaire, parce que je ne suis pas un gros égoïste de base, et que j'aime bien partager les trucs que je trouve cool et que tout le monde en profite.
Partant de là, je ne vois pas en quoi cela est gênant qu'il y ait ce genre de choses sur "mon OS préféré" et en quoi ça le rendrait moins bien sur les points que j'ai cité plus haut (j'en ai certainement oublié quelques uns au passage)
Moi je trouve que c'est une affaire de goût. Est-ce une affaire de goût de savoir si c'est une affaire de goût ? :-)
Certains projet ne laisse pas passer un code avec des accolades en trop en review. (ex: Qt)
Et d'autres veulent des espaces, et d'autres veulent des tabs. Moi j'apelle ça une affaire de goût.
La différence entre espaces et tab, la taille des espaces, la position des accollades, si les parentheses sont collées ou pas à ce qu'elle contiennent, je classe également tout cela dans le style.
Mais le coup de ne pas mettre d'accolades lorsqu'il n'y a qu'une seule instruction avec un if, j'ai vraiment du mal.
C'est vrai que tous les arguments auquels je pense, peuvent être appliqués aux autres cas, mais quand même, ça crée une différence artificielle entre les cas 1 et plusieurs instructions, et je trouve que c'est beaucoup plus sujet à erreur que les autres.
Je ne veux pas défendre les « mauvaises pratiques ».
Je critique: « Oh une faille, c'est à cause des mauvaises pratiques, c'est vraiment des incompétants chez Apple ».
Ce serait plutôt du même accabit que « Il a eu un cancer, donc c'est un con (car les fumeurs sont des cons) », qui est assez irrespectueux en plus d'être fallacieux.
Moi je dirais, il a eu un cancer, c'est vraiment pas cool pour lui. Mais son mode de vie n'était vraiment pas très sain, du coup c'est quelque chose qui lui pendait au nez plus qu'à d'autres !
Sinon, la différence est que le type qui a un cancer, déjà c'est vraiment terrible pour lui et son entourage ! Mais ensuite, si cela viens de son tabagisme, c'est lui qui ne prenait pas soin de lui même, à moi il ne m'a rien fait et je n'ai pas de raisons de lui en vouloir ni de l'accabler plus !
Là, on parle de professionnels qui vendent un produit, sans dire que c'est des cons, dans ce cas c'est plutôt de nous qu'ils se moquent, car c'est nous qui en patissons en utilisant leur produits au final. Ça terni leur réputation et la confiance qu'on leur octroi. (même si elle frisait déjà le zéro pour ma part)
Après, il y a peut-être également une certaine frustration des gens ici car ils entendent souvent vanter apple et ses produits, alors ils se lâchent un peu…
On est d'accord. « plus difficlie », mais toujours possible. Donc l'existence d'une faille ne prouve pas que les pratiques sont mauvaises.
Ça n'est pas ce que j'ai dit, j'ai dit que cela réduisait les risques, et que statistiquement, je pense qu'il devrait y en avoir moins dans une grosse base de code si elle a été écrite en suivant de "bonnes pratiques" en terme de style mais aussi de technique de codage.
Après, entre ce que je pense et la réalité…
Pour reprendre l'analogie du cancer, il y a des gens qui ont un mode de vie très sain qui finissent malheuresement par en avoir un.
(c'est beau les trolls sur la cigarette en plein débat sécurité des produit apple !! je suis fier de moi pour le coup !)
Chacun ces goûts. On peux troller autant qu'on veut sur tab/espace, niveau d'indentation, acolade ou non.
En l'occurence, je ne trouve pas que le manque d'accolades soit une affaire de goût.
Le C l'autorise, mais je trouve que c'est une mauvaise pratique, en tout cas, je ne laisse en aucun cas passer un code comme cela en revue chez moi.
C'est le cas de quasiment toutes les faille ou bugs. Je ne prendrais pas cet example comme une peuve de mauvaise pratique. Des bugs arrivent dans tout les projets.
C'est vrai que ça arrive dans tous les projets, même ceux ayant de bonnes pratiques (on en parle un peu dans les commentaires précédents, parait-il)
Mais les mauvaises pratiques de code peuvent accentuer le problème et ajouter de nouvelles failles.
Donc le "ça arrive même à ceux qui codent bien" est du même accabi que lorsque j'entends des gens dire "il a eu un cancer à 45 ans et il ne fumait pas, alors je m'en fou, je peux fumer 3 paquets par jours !"
Peut être aussi que cette « erreur » est volontaire.
Ça c'est un autre problème. Mais là encore, avec de bonnes pratiques, une erreur volontaire est plus difficile à dissimuler.
Là tu parles d'interface graphiques, déjà branchées par dessus des abstractions (libc, c++, X11, wayland)
En l'occurence, systemd est la couche basse, directement branchée sur le noyau.
Or la principale différence entre un linux et un BSD est … le noyau, linux ou BSD.
Du coup je ne vois pas comment faire un truc portable directement au dessus du noyau, à moins de faire une lib d'abstraction intermédiaire ? qu'on appellerai libsystem, et par dessus, on aurait notre outil portable, que l'on pourrait appeler libbus !
J'ai la solution !!
Il suffit de faire une boite de dialogue de mot de passes qui esquive quand on veut y entrer son mot de passe :D
Du coup, quand ce sera trop facile pour les autres, l'utilisateur se doutera forcément de quelque chose !
Faut penser à activer les webcam pour filmer la tête des utilisateurs au passage :D
Le soucis c'est que tu compares avec ce qui t'arrange pour dire que cela ne te conviens pas.
Je pourrais aussi dire que je souhaites un système qui contrôle l'accès à mes fichiers en fonction de l'utilisateur et des droits du fichier.
Lequel des deux énoncés est plus proche du cas compositeur wayland ?
Moi je trouve l'article très intéressant.
Et je trouve cela correcte qu'à partir du moment où le rendu à l'écran soit du ressort du compositeur, et que l'on décide d'en restrindre l'accès à l'application, et bien que cette restriction soit complètement gerée par le compositeur.
Pour l'analogie avec l'accès à un fichier, je dirais aussi que les cas d'utilisation sont très différents !
L'utilisation de ton système étant très dépendante de l'accès à des fichiers, il est difficile d'en restreindre l'accès arbitrairement sans remettre en cause énormément de choses.
Pourtant, c'est bien ce qui est en train de se faire avec les exécutions dans des bac à sable sur les systèmes mobiles entre autre qui n'ont pas ce lourd historique applicatif à gerer !
Et du coup ça n'est peut-être pas une si mauvaise idée que cela, juste qu'elle est vraiment trop difficilement applicable à l'existant.
Mais vu que wayland et ses compositeur sont nouveaux (rien à voir avec le driver nvidia…), autant essayer d'améliorer les choses là où c'est possible sans remettre en cause trop d'applications et de cas d'utilisation existants.
[^] # Re: Logiciel plaçant son propre code source en mémoire
Posté par moi1392 . En réponse au journal Heartbleed : petit best of des journalistes. Évalué à 2.
Tout ce qui passe par la mémoire du processus !
Je ne connais pas assez l'architecture des serveurs web, mais est ce que, par exemple, apache, fait tounrer dans le même process, la compilation du php, leservicede page web et le protecole de communication, en particulier les algos de chiffrement ?
Tout ce qui est exécuté dans des processus séparés devrait à priori ne pas devoir être impacté, non ?
[^] # Re: Rollbacks
Posté par moi1392 . En réponse au journal APT : nouvelle version 1.0. Évalué à 3.
L'installation de ton paquet n'écrit pas forcément directement dans ton home, mais l'utilisation du logiciel installé y sauvegarde généralement ses préférences.
Et il arrive que le format change et devienne incompatible avec une ancienne version.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par moi1392 . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 1. Dernière modification le 05 avril 2014 à 12:21.
Je n'arrive pas avec du code imbitable généré par lex. J'arrive avec un fichier lex lisible qui est compilé pendant la phase de compilation.
"Bonjour, j'ai ré-écrit le gros pathé de code imbitable en une série de strcmp(), J'ai économisé 3 Kio de taille de binaire en x86, et en plus j'enlève 50 lignes de code"
Il n'aura rien ré-écrit du tout car ce "pathé de code imbitable" n'est pas écrit. Encore une fois, c'est un fichier lex simple, très lisible (pour peu que l'on conaisse la syntaxe, comme tout format de fichiers) et sincèrement très compliqué à battre, tant en terme de performance que de consomation mémoire (bon, peut-être pas en consomation, mais c'est pas la mort non plus)
Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format, et quand j'ai à analyser cela, je crée un analiser lexical avec lex que je couble avec un petit switch. Tu as remarqué que dans mon post original, je prenais soin de mentionner que je ne couplais en aucun cas ça avec du yacc/bison.
Encore une fois, si j'ai 3 mots clés que je lis 2 fois chacuns, je ne le fais pas. Quand cela commence à gonfler, c'est le tas de if/else avec des comparaisons de chaines qui deviens du bloat.
Une fois encore, je n'écris pas de grammaire !! juste un automate à état finis généré par lex que je couple avec un switch en C
Après si c'est lex qui te donne des boutons, tu n'as qu'à l'écrire à la main ton automate, mais tu seras moins bon que lui et quand ce que tu auras à parser change, il faudra le réécrire, c'est pas terrible.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par moi1392 . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.
c'est un monologue ????
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par moi1392 . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
Au passage, je sais que git n'est pas un composant critique en terme de sécurité, mais ça ne coutait pas grand chose de mettre des strNcmp.
D'ailleurs, il y en a un au milieu qui est un memcmp, ça ne doit pas être la même personne qui l'a écrit, celui là :)
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par moi1392 . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
Ça marche quand tu en as un nombre assez faible et que tu n'as pas besoin de performances importantes.
Dans ce cas là oui, je trouve même que c'est plus lisible de la sorte.
Mais j'ai un peu de mal à appeler cela un parser (ou un analyseur lexical)
Mais si tu dois passer à la moulinette de plus gros fichiers, que tu as beaucoup de mots clés à y reperer et qui peuvent revenir souvent (et c'est le cas pour des fichiers de configuration), je pense qu'utiliser flex (sans l'associer à bison) et plus efficace et maintenable (ajout de nouveaux mots clés, de patterns, …)
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par moi1392 . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 4.
Un parser pour moi, ça se code avec un automate à état fini quand on est étudiant, et ensuite on utilise lex qui le fait à ta place.
Le coup du gros bloc de if avec des str(n)cmp, je trouve ça assez moyen (euphémisme)
[^] # Re: Hardcoder ?
Posté par moi1392 . En réponse au journal Les artistes, ce fléau ou l'invasion des profanateurs de GUI. Évalué à 4.
Ou sinon tu fais au moins un vrai test avant de sortir le produit, et tu évite les changements après le début de la phase de test, on est en phase de dévelopement/debogague là.
Si tu ne testes même pas le menu de base avant la sortie de ton produit, j'ai de fort doutes sur sa qualité globale, même s'il est écrit avec un super algo de la mort qui tue.
[^] # Re: Hardcoder ?
Posté par moi1392 . En réponse au journal Les artistes, ce fléau ou l'invasion des profanateurs de GUI. Évalué à 2. Dernière modification le 20 mars 2014 à 13:48.
tu utilises un fichier texte pour stocker la config, comme ça tu leurs explique comment faire ça et ils se débrouillent !
Tu verras qu'ils auront tout de suite moins envie de tout changer toutes les 5 minutes :)
Et une fois encore, c'est u menu, s'il y a 4 entrée, c'est pas trop la mort d'écrire un truc du genre (très verbeux pour l'exemple, on peut faire beaucoup mieux)
c'est franchement pas la mort, et même si ça change souvent, ça reste simple a décrire et même un designer peut le faire !
[^] # Re: Hardcoder ?
Posté par moi1392 . En réponse au journal Les artistes, ce fléau ou l'invasion des profanateurs de GUI. Évalué à 4.
à priori ça n'est que la direction qui pose problème dans ton cas, donc tu as 4 (direction) * m (nombre de menus) à définir.
m n'est pas sensé être trop grand non plus, je ne pense pas que ce soit excessif.
tu étends l'api jnuit et au lieu de lui donner la position d'un bouton, tu lui donne sa position + ses transitions.
dans le cas ou tu utilise la première api, tu gardes ton ancien algo, avec la nouvelle api, les transitions sont données de ton coté.
Du coup tu auras même amélioré ta lib en la rendant plus souple :)
[^] # Re: Hardcoder ?
Posté par moi1392 . En réponse au journal Les artistes, ce fléau ou l'invasion des profanateurs de GUI. Évalué à 2.
Je suis globalement d'accord, à moins que la position de tes menus ne soit choisi aléatoirement à chaque fois que tu lances ton application, elle est figée une fois pour toute, c'est de l'aléatoire, mais pas trop (http://xkcd.com/221/)
donc une fois que les artistes se sont mis d'accord sur la position des menus, tu décide de l'ordre de navigation et tu le codes en dur.
[^] # Re: Très instrcutif !
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E10 : génération procédurale de carte (partie 1). Évalué à 4.
Ce lien est parfait, merci :)
Je pense que cela vaut le coup d'éditer la dépêche pour le rajouter !
[^] # Re: Très instrcutif !
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E10 : génération procédurale de carte (partie 1). Évalué à 2.
Oups, je n'étais pas remonté jusque là !
Et du coup, ma tentative d'explication est fausse par rapport à ta notation !
Dans ce cas, ce qui m'a induit en erreur est la début de la phrase : "Pour le point A"
J'ai vraiment pensé qu'il s'agissait d'un point final pour lequel on veut une valeur d'altitude.
# Très instrcutif !
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E10 : génération procédurale de carte (partie 1). Évalué à 3. Dernière modification le 13 mars 2014 à 16:54.
Salut, j'ai trouvé ton article très intéressant et instructif !
Tu m'as donné envie de recoder des trucs (oui je sais, je dis ça un article sur deux dans ta série de dévelopement de jeux vidéo… mais là promis, j'y crois :))
Juste queslques précision sur des points que j'ai eu un peu de mal à comprendre :
Sans lire le papier "terrain generation" sur lequel tu mets un lien en début d'article, c'était complètement obscur et incompréhensible pour moi.
Qu'est ce qu'une octave ?
À quoi corresponds l'amplutide ? la fréquence ?
Après l'avoir lu, j'ai compris, et je ne suis pas sur de savoir mieux l'expliquer, mais peut etre rapprocher cette phrase du lien ou donner un exemple simple avec 2 ou 3 (ça risque d'être trop long) octaves, en détaillant complètement l'algo et les calculs, pourrait aider.
le point P n'étant pas défini, j'ai cru au début à une faute de frappe de ta part, j'ai compris ensuite que je n'avais pas compris ;)
Mais je pense que cette partie mérite aussi une explication supplémentaire.
Comme par exemple définir les 4 (ou n, pour un hypercube) points Pi autour de A et Gi le gradient en Pi. Enfin, poser le produit scalaire Gi.(Pi-A) comme dans le papier de Perlin (c'est une suggestion de présentation, bien sur, mais moi ça m'aurait aidé à comprendre beaucoup plus vite)
Sinon c'est vraiment chouette :)
Je n'ai pas encore approfondi la partie ombres, mais elle m'intéresse aussi.
Je vais peut-être reprendre (dès que le soleil repartira…) le code de génération de terrain aléatoire que j'avais tenté décrire en vains lorsque j'étais étudiant.
la technique que j'avais imaginé à l'époque, et qui ne marchait pas du tout, fonctionnait "dans l'autre sens" de ce que tu décris ici, à savoir créer une map aléatoire, et appliquer des filtres de moyenne et de lissage pour obtenir un résultat.
Le problème est que pour avoir quelques chose de correct, il faut faire beaucoup d'itérations, et du coup la carte se retrouvait avec un relief très faible.
Et lorsque j'ai tenté de baisser la fréquence de map carte aléatoire de départ, je voyais clairement apparaitre des artéfact carrés dans mon résultat.
Il faut dire aussi que mes techniques de lissage étaient basé sur des moyennes polynomiales (linéaires ou quadratiques pour la plupart), pas du tout adaptées :)
Pour les ombres, comme je faisais du rendu 3d (avec OpenGL), je n'avais pas de soucis particuliers.
[^] # Re: et les 4 libertés? oubliées?
Posté par moi1392 . En réponse au journal [journal marque page] quelques nouvelles intéressantes pour le jeu linux. Évalué à 1.
Désolé, j'ai seulement répondu au commentaire de Jiel.
Mais de mon coté, je dois dire que vogl est un projet qui m'intéresse beaucoup et il y a de fortes chances que je l'utilise à moyen terme !
Donc d'un point de vu logiciels libres, c'est quelque chose de très intéressant aussi :)
[^] # Re: et les 4 libertés? oubliées?
Posté par moi1392 . En réponse au journal [journal marque page] quelques nouvelles intéressantes pour le jeu linux. Évalué à 8. Dernière modification le 13 mars 2014 à 12:03.
Non, si tu n'en veux pas, ne les utilise pas, ça ne change rien à ta façon d'utiliser ton OS aujourd'hui !
L'auteur du journal à l'air de n'avoir pas de soucis particuliers avec ce point et accepte la boite noire, donc pas de soucis.
Au passage, si tu veux quand même utiliser ce genre de logiciel mais que le coté boite noire te gêne, il y a une solution intermédiaire qui serait de créer un utilisateur "jeux" qui ne sert qu'à cela, ça n'est pas la panacée et tu t'expose toujours au des attaques sur des failles de type escalade de privilège, cassage des mots de passe des autres utilisateurs par brute force, mais c'est toujours un peu mieux pour te protéger des techniques simple de tracking et d'espionnage de ta vie privée que de tout avoir sous le même compte.
[^] # Re: Si seulement
Posté par moi1392 . En réponse au journal [journal marque page] quelques nouvelles intéressantes pour le jeu linux. Évalué à 7.
Perso, je suis un peu comme beaucoup de monde ici (à en lire les commentaires, je me trompe peut-être) et le fait qu'il y ait plus de parts de marché ne m'intéresse que dans la perspective que pour de logiciels soient portés et maintenus, que les pilotes soient de meilleur qualités, les périfériques tous supportés, …
Mais des parts de marché pour des parts de marché, je m'en fou un peu.
Et le fait que des personnes y passeraient pour des exclus ne me réjouis pas spécialement.
D'ailleurs je trouve cela con qu'il y ait des exclus. Qu'il y en ait parce que les gens développent dessus et n'aient pas le temps, les compétences pour porter les logiciel ailleurs, ça me parait normal et logique, mais que cela soit une exclus juste pour dire "on a la plus grosse" je trouve cela con.
[^] # Re: et les 4 libertés? oubliées?
Posté par moi1392 . En réponse au journal [journal marque page] quelques nouvelles intéressantes pour le jeu linux. Évalué à 10. Dernière modification le 13 mars 2014 à 11:09.
"notre OS préféré" ???
Moi, c'est mon os préféré parce que je fais ce que j'en veux !
Parce que l'os ne me mets pas de bâtons dans les roues volontairement pour me limiter ou décide à ma place ce que est le mieux pour moi sans me laisser d'alternative.
Parce que je le trouve plus performant, pratique et simple d'utilisation (oui oui) que les autres.
Et aussi pour son coté communautaire, parce que je ne suis pas un gros égoïste de base, et que j'aime bien partager les trucs que je trouve cool et que tout le monde en profite.
Partant de là, je ne vois pas en quoi cela est gênant qu'il y ait ce genre de choses sur "mon OS préféré" et en quoi ça le rendrait moins bien sur les points que j'ai cité plus haut (j'en ai certainement oublié quelques uns au passage)
# comefrom > goto !
Posté par moi1392 . En réponse au journal <3 goto. Évalué à 3.
goto, c'est dépassé, les vrais codeurs utilisent comefrom maintenant !
http://c2.com/cgi/wiki?ComeFrom
[^] # Re: Code défensif
Posté par moi1392 . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 4.
La différence entre espaces et tab, la taille des espaces, la position des accollades, si les parentheses sont collées ou pas à ce qu'elle contiennent, je classe également tout cela dans le style.
Mais le coup de ne pas mettre d'accolades lorsqu'il n'y a qu'une seule instruction avec un if, j'ai vraiment du mal.
C'est vrai que tous les arguments auquels je pense, peuvent être appliqués aux autres cas, mais quand même, ça crée une différence artificielle entre les cas 1 et plusieurs instructions, et je trouve que c'est beaucoup plus sujet à erreur que les autres.
Moi je dirais, il a eu un cancer, c'est vraiment pas cool pour lui. Mais son mode de vie n'était vraiment pas très sain, du coup c'est quelque chose qui lui pendait au nez plus qu'à d'autres !
Sinon, la différence est que le type qui a un cancer, déjà c'est vraiment terrible pour lui et son entourage ! Mais ensuite, si cela viens de son tabagisme, c'est lui qui ne prenait pas soin de lui même, à moi il ne m'a rien fait et je n'ai pas de raisons de lui en vouloir ni de l'accabler plus !
Là, on parle de professionnels qui vendent un produit, sans dire que c'est des cons, dans ce cas c'est plutôt de nous qu'ils se moquent, car c'est nous qui en patissons en utilisant leur produits au final. Ça terni leur réputation et la confiance qu'on leur octroi. (même si elle frisait déjà le zéro pour ma part)
Après, il y a peut-être également une certaine frustration des gens ici car ils entendent souvent vanter apple et ses produits, alors ils se lâchent un peu…
Ça n'est pas ce que j'ai dit, j'ai dit que cela réduisait les risques, et que statistiquement, je pense qu'il devrait y en avoir moins dans une grosse base de code si elle a été écrite en suivant de "bonnes pratiques" en terme de style mais aussi de technique de codage.
Après, entre ce que je pense et la réalité…
Pour reprendre l'analogie du cancer, il y a des gens qui ont un mode de vie très sain qui finissent malheuresement par en avoir un.
(c'est beau les trolls sur la cigarette en plein débat sécurité des produit apple !! je suis fier de moi pour le coup !)
[^] # Re: Code défensif
Posté par moi1392 . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 2.
En l'occurence, je ne trouve pas que le manque d'accolades soit une affaire de goût.
Le C l'autorise, mais je trouve que c'est une mauvaise pratique, en tout cas, je ne laisse en aucun cas passer un code comme cela en revue chez moi.
C'est vrai que ça arrive dans tous les projets, même ceux ayant de bonnes pratiques (on en parle un peu dans les commentaires précédents, parait-il)
Mais les mauvaises pratiques de code peuvent accentuer le problème et ajouter de nouvelles failles.
Donc le "ça arrive même à ceux qui codent bien" est du même accabi que lorsque j'entends des gens dire "il a eu un cancer à 45 ans et il ne fumait pas, alors je m'en fou, je peux fumer 3 paquets par jours !"
Ça c'est un autre problème. Mais là encore, avec de bonnes pratiques, une erreur volontaire est plus difficile à dissimuler.
[^] # Re: Le nid à trolls
Posté par moi1392 . En réponse au journal systemd ca a l'air super.... Évalué à 5.
Là tu parles d'interface graphiques, déjà branchées par dessus des abstractions (libc, c++, X11, wayland)
En l'occurence, systemd est la couche basse, directement branchée sur le noyau.
Or la principale différence entre un linux et un BSD est … le noyau, linux ou BSD.
Du coup je ne vois pas comment faire un truc portable directement au dessus du noyau, à moins de faire une lib d'abstraction intermédiaire ? qu'on appellerai libsystem, et par dessus, on aurait notre outil portable, que l'on pourrait appeler libbus !
Je tiens un truc là je crois…
[^] # Re: Le nid à trolls
Posté par moi1392 . En réponse au journal systemd ca a l'air super.... Évalué à 10.
Je crois qu'il y a un léger soucis de compatibilité entre ces deux points.
[^] # Re: Boite de dialogue pour les mots de passe
Posté par moi1392 . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 3. Dernière modification le 21 février 2014 à 11:45.
J'ai la solution !!
Il suffit de faire une boite de dialogue de mot de passes qui esquive quand on veut y entrer son mot de passe :D
Du coup, quand ce sera trop facile pour les autres, l'utilisateur se doutera forcément de quelque chose !
Faut penser à activer les webcam pour filmer la tête des utilisateurs au passage :D
[^] # Re: Capture d'écran
Posté par moi1392 . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 6.
Le soucis c'est que tu compares avec ce qui t'arrange pour dire que cela ne te conviens pas.
Je pourrais aussi dire que je souhaites un système qui contrôle l'accès à mes fichiers en fonction de l'utilisateur et des droits du fichier.
Lequel des deux énoncés est plus proche du cas compositeur wayland ?
Moi je trouve l'article très intéressant.
Et je trouve cela correcte qu'à partir du moment où le rendu à l'écran soit du ressort du compositeur, et que l'on décide d'en restrindre l'accès à l'application, et bien que cette restriction soit complètement gerée par le compositeur.
Pour l'analogie avec l'accès à un fichier, je dirais aussi que les cas d'utilisation sont très différents !
L'utilisation de ton système étant très dépendante de l'accès à des fichiers, il est difficile d'en restreindre l'accès arbitrairement sans remettre en cause énormément de choses.
Pourtant, c'est bien ce qui est en train de se faire avec les exécutions dans des bac à sable sur les systèmes mobiles entre autre qui n'ont pas ce lourd historique applicatif à gerer !
Et du coup ça n'est peut-être pas une si mauvaise idée que cela, juste qu'elle est vraiment trop difficilement applicable à l'existant.
Mais vu que wayland et ses compositeur sont nouveaux (rien à voir avec le driver nvidia…), autant essayer d'améliorer les choses là où c'est possible sans remettre en cause trop d'applications et de cas d'utilisation existants.