moi1392 a écrit 740 commentaires

d'ailleurs, je ne sais pas comment elle s'en sort, il me semblait (et après vérification, c'est bien le cas) que c'était implémenté avec un rb-tree.
Du coup ta réponse devrait être la bonne est l'accès au plus petit élément devrait être de complexité log(n)

tu m'as mis le doute, mais la doc n'est pas d'accord avec toi : http://www.cplusplus.com/reference/map/map/begin/

complexity : constant

ça permet d'insérer en O(log n)

c'est donc unse insertion triée ;) ce que tu décris, c'est une std::map (implémenté par un red/black tree au moins dans la lib c++ livrée avec gcc)

Surtout, le problème que je vois, c'est que les cases sont en plusieurs exemplaires dans la file. Comment tu gères ça ?

Un élément de ta file, c'est (case, altitude), si deux paires (case, altitude) sont identiques, l'insersion n'a rien à faire, sinon tu as un nouvel élément qui est différent.

Au moment de transformer une case de terrain en rivière, tu prends le premier élément de ta liste, et si c'est déjà de l'eau (parce qu'il avait été inserée et déjà converti avant), et bien tu le zappes juste.

Effectivement, je crois qu'il y a du flou. Parce qu'il parle de mettre une case potentiellement deux fois, ou de mettre à jour son potentiel. Dans les deux cas, je ne vois pas bien comment on fait.

je parlais bien de mettre une case avec son potentiel dans la liste. ET à ce moment là, si la même case se retrovuve avec un potentiel différent (car venant d'ailleurs), cela fait un élément different de la liste, donc pas de soucis.

enfin, pour le tri, tu ne le fait que sur le potentiel, donc cela ne devrait pas etre beaucoup plus lent (en fait, j'avais plutôt cru comprendre que c'est une insersion triée que tu fais et pas un tri global à chaque fois)
La complexité est ajoutée au moment d'ajouter un élément dans ta liste triée. Il faut pondérer son altitude absolue par un facteur "judicieusement" choisi.
Et ça, je conçois tout à fait que ça n'est pas trivial.

Mais une fois ce mécanisme en place, tu peux essayer plusieur facteurs de pondération et voir comment ils influent sur le résultat ! (cf, le second message de mes 2 posts successifs)

64 ko me parait très peu, est ce que tout ce qui est affiché est purement paramétrique et construit à partir d'équations ? Où y a-t-il des données qui ne sont pas dans l'exécutable et pas contabilisés ?

Quid des libs aussi ? parce que rien que libGL.so, ça fait déjà un joli paquet de Mo…

et tant qu'on y est, si cette solution marche, on pourrait même imaginer favoriser les lignes droites de la même façon, en ajoutant un petit aléa dans les altitudes des cases adjacentes.
Alea inférieur à la différence d'altitude minimale entre 2 cases, car cela reste le critère le plus important, mais qui aurait un légère chance d'être plus élevé si la rivière continue en ligne droite plutôt que de tourner !

Ça complique la chose en effet.

Mais quand tu insères ta case dans ta file, tu sais d'où tu viens, non ? donc tu peux utiliser une altitude absolue "ajustée" pour le tri à ce moment là.
Et si tu retombes sur la même case en venant d'ailleurs, rien ne t'empêche de l'insérer une seconde fois avec une autre altitude ajustée !

Ça te parait raisonnable ?

C'est sans doute aussi un biais au niveau des données, parce qu'en allant en diagonale, tu as plus de chance d'avoir une différence d'altitude plus élevée qu'avec la case à côté.

Est ce que tu pondères la différence d'altitude avec la distance ? vu que tes tuiles sont carrées, on peut considérer qu'une case sur le coté est à une distance de 1 et qu'une case sur la diagonale à une distance de

Du coup suffit de chiffrer ses messages avec un algo nsa et de rechiffrer le résultat avec un algo kgb et on est tranquille \o/

Voila le vrai lien

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.

Ca servirait à quoi ?

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.

c'est un monologue ????

Par exemple dans git:
https://git.kernel.org/cgit/git/git.git/tree/builtin/commit-tree.c#n43

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, …)

En même temps le code d'un parseur est généralement bourré de suites de 'while (readline) { if (strncmp(' etc. etc.

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)

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 !

à 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 :)

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.

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 :)