rewind a écrit 3416 commentaires

Pour quiconque connaît le mouvement, il est flagrant que c'est la théorie du genre qui est à l’œuvre.

Es-tu sûr que ce ne sont pas les chinois de la NSA ? Ou le grand complot judéo-maçonnique ?

C'est vrai ! Voilà la version longue :

En tout cas ça fournit une GUI et un certain nombre de briques de bases pour ce que tu veux faire.

Ce que je veux faire, c'est vite dit. J'ai un jeu à faire ! Donc, j'ai mis ça comme idée si quelqu'un se sent l'envie de le faire. Ou alors, je donnerai ça à des étudiants, juste pour voir ce que ça peut donner.

Pas satisfait non plus. GEM est très orienté OpenGL, mon outil est pour l'instant orienté pixels. Après, Pure Data peut être spécialisé pour des heightmap, de la même manière que GEM a spécialisé Pure Data pour le graphique. Mais est-ce que ça vaut bien le coup par rapport à un développement from scratch ?

Est-ce que ça vaut le coup de devoir lancer Blender pour générer des heightmaps ? Il me semble que détourner un outil tel que Blender pour faire totalement autre chose, c'est contre-productif.

Merci pour ce conseil ! En fait, je pensais que la copy-ellision était difficile à détecter et donc qu'elle ne se produisait que dans de rares cas. En fait, c'est le contraire ! Du coup, je vais aller supprimer mes move.

Oui, ça correspond à ça sauf que là, c'est hyper spécialisé et en regardant vite fait, je ne crois pas que ce soit adaptable à mon cas. C'est dommage parce que ça correspond assez bien à ce que j'aimerais avoir.

Merci pour ces bonnes références ! Effectivement, j'imaginais plutôt ce genre de choses. Ça sera une bonne source d'inspiration le moment venu, le rendu est plus que convenable.

Du coup ça me fais pensé qu'il pourrait être intéressant d'avoir un système de marées ou certaines zones ne sont accessible qu'a marée base genre le mont st Michel sans cette horrible digue.

Intéressant mais difficile comme tu le supposes par la suite. Parce qu'il faut pouvoir modifier la carte de base sur de grandes zones, ce qui peut être compliqué suivant le format de la carte (en mémoire). Dans mon cas, je n'avais pas prévu ce genre de choses donc ça ne va pas être possible. Mais l'idée est intéressante.

Les vieux RPG 2D l'utilisent beaucoup, comme les montagnes au nord de Link's Awakening.

Oui mais là, c'est de la fausse vue de dessus. Dans mon jeu, j'ai pris le parti de faire de la vue de dessus vraiment dessus, à la verticale. Du coup, on ne peut pas utiliser ce genre d'astuce pour simuler le relief.

Finalement, je me suis simplement penché sur un bête A* en utilisant la topologie de la carte comme heuristique, le résultat s'est montré satisfaisant dans le cadre du projet sur lequel je travaille, bien qu'il montrerait très vite ses limites si on cherche à représenter un monde trop réaliste.

C'est intéressant comme algorithme, j'en ai un qui ressemble un peu. Et sur le côté réaliste, je dirais qu'on est dans un jeu vidéo, donc on peut prendre quelques libertés. Je ne suis pas géographe !

Puisque, si j'ai bien compris, tu travaille sur un jeu 2d, comment penses tu représenter visuellement une topologie aussi précise que celle que ton algorithme est capable de générer ?
Au final, sous quelle forme vas tu représenter le monde au joueur ? Vas tu granulariser ta carte pour l'afficher sous forme de tuiles, comme la plupart des jeux 2d ?

L'idée, pour la suite, c'est de dire qu'un pixel sur la carte d'altitude, c'est une tuile sur la carte finale. J'ai déjà une carte sous forme de tuile (voir l'épisode 7), mais pour l'instant, elle est un peu basique. Le tileset est moisi, les couleurs sont horribles. Je vais donc définir un tileset, puis définir pour chaque case quelle tuile convient le mieux, en fonction de l'altitude, mais pas que.

Une difficulté, comme tu le dis, c'est de représenter le relief et la pente en vue de dessus. Je pense que c'est hyper difficile, et que ça n'apporte pas grand chose étant donné le niveau de zoom sur le personnage. Mais on peut donner des indices visuels qui permettent, pour certaines situations (comme les zones infranchissables) de suggérer qu'il y a un relief. Et on peut toujours permettre au joueur de voir une grande carte générée par mon programme en l'état actuel pour qu'il voit les reliefs ;)

Comptes-tu utiliser des graines différentes pour chaque partie afin de générer des niveaux aléatoires, ou n'est-ce qu'un moyen pour toi d'accélérer et de simplifier le level-design d'un monde unique ?

Je suis clairement dans la deuxième solution. Je veux un monde assez grand et je ne veux pas m'occuper de tous les détails, surtout ceux qui peuvent être délégués à un algorithme. Donc, j'ai écris ces algos pour pouvoir générer des mondes et en choisir un qui me servira pour mon jeu. Dans la partie 2, je montrerai tout ce que je génère en plus pour éviter de me fatiguer ;) Mais clairement, si je devais tout générer, y compris les quêtes et tout ça, ça serait un travail énorme et d'une difficulté largement supérieure à ce que j'ai fait là.

Ho, il aime pas le using dans la définition de l'exception. Bon, ça va, c'est possible de traiter ce problème aussi. Du coup, j'ai ajouté deux bugs sur github pour m'en souvenir, merci !

oui, ça compile, et ensuite il y a d'autres erreurs

Tu peux me les indiquer. Pour d'autres lib, j'ai prévu un mode sans C++11 de toute façon, je peux faire pareil ici dans la mesure du possible.

J'ai oublié d'en parler, mais ces techniques sont encore utilisées de nos jours. Notamment dans Minecraft où les terrains sont générés à base de bruit de Perlin. Et beaucoup d'éditeurs de niveaux pour des jeux modernes ont un module qui permet de générer des terrains à partir des techniques présentées ici. Donc, ces techniques ne sont pas mortes, au contraire. Mais elles ne sont plus intégrées dans les jeux, elles servent justes de base pour éviter de passer trop de temps sur des tâches sans intérêt. Ensuite, une fois la base générée, on peut décorer la carte comme on veut.

Pour le bug, c'est juste que GCC 4.7.2 ne gère pas C++11 entièrement (la gestion est complète à partir de GCC 4.8.1). Et donc, la fonction emplace qui permet de construire l'élément directement dans la map n'existe pas dans les vieilles versions. Tu peux remplacer la ligne incriminée par (pas testé mais ça doit passer) :

  m_map.insert(std::make_pair(offset, c));

Pour ta deuxième question, oui on peut. Il suffit d'implémenter un générateur qui lit un fichier contenant une heightmap. Et ensuite, on applique des opérateurs d'érosion (qui sont définit de manière indépendante dans MapMaker). Si la carte est en couleur, ça peut être assez compliqué à lire, généralement les heightmaps sont en dégradé de gris. La carte que tu montres, c'est le résultat que tu veux avoir ou c'est le point de départ ?

La génération de rivière, ça sera pour la partie 2. Et oui, j'y ai déjà réfléchi (ou plutôt, deux de mes étudiants y ont réfléchi) et il existe plusieurs algorithmes possibles. Les plus naïfs ne marchent pas bien en fait, soit parce qu'ils sont beaucoup trop long, soit parce qu'ils ne donnent pas de bons résultats. Du coup, il faudra un peu patienter ;)

Ça dépend. Moi, j'enregistre ce que je soumets (sauf quand ça passe par la tribune de rédaction). Et c'est vrai que je me suis déjà fait la même réflexion que celui qui a soumis le bug. L'export Markdown me va parfaitement ! Et même pour celui qui n'a pas sauvegardé son texte, ça lui permet de pouvoir le faire facilement.

Je vois d'ailleurs que ça a été déployé ce soir.

Je n'arrive pas à trouver la bonne page, je crois. Je pense que je ne cherche pas au bon endroit… Tu peux m'aider ?

Techniquement, comment tu fais ? Tu aurais un tutoriel ou un jeu qui fait comme tu le décris ?

Étant le premier développeur de Jyraphe, je suis très content de voir Jyraphe voler de ses propres ailes (même si une jyraphe n'a pas d'aile). C'est vrai que j'ai délaissé ce projet depuis bien longtemps, par manque de temps et surtout manque d'intérêt. Il y a eu quelques pics d'activités sporadiques sur la mailing-list ces dernières années mais je n'avais plus l'envie pour m'y investir autant qu'il aurait fallu. Et donc, la conséquence naturelle, c'est que pas mal de forks sont apparus. Ce qui est très bien !

Après, mon souhait serait de fermer définitivement le projet sur GNA (virtuellement), puisqu'il est évident qu'il ne reprendra plus et que les forks apportent tout ce qu'il faut. Et j'aimerais aussi pouvoir rediriger les personnes intéressées et qui arrivent sur la page GNA vers les bons forks, puisque, comme je le comprends, chacun de ces forks n'a pas les mêmes objectifs d'évolution. Est-ce que ceux qui trainent par ici et qui sont impliqués dans ces forks sont d'accord pour ça et aussi, est-ce que la description de jihele un peu plus haut dans les commentaires pourraient convenir ?

Soit 7 jours, 15 dépêches sur la première page (!?).

Pas très représentatif. Essayons avec plusieurs pages pour se faire une idée :

• page 1 : 25/02 - 18/02 : 7 jours
• page 2 : 18/02 - 13/02 : 5 jours
• page 3 : 13/02 - 11/02 : 2 jours
• page 4 : 11/02 - 07/02 : 4 jours
• page 5 : 07/02 - 02/02 : 5 jours
• page 6 : 02/02 - 27/01 : 6 jours
• page 7 : 27/01 - 20/01 : 7 jours
• page 8 : 19/01 - 14/01 : 5 jours

J'arrête là. On peut aussi regarder les statistiques de l'an dernier. Il y a eu 1035 dépêches, soit environ 2,84 dépêches par jour. Avec 15 dépêches par page, les dépêches restent donc en moyenne 5,29 jours. Et c'est une moyenne, on voit avec les chiffres au dessus que c'est très variable. Pour celui qui a écrit une longue dépêche qui est publiée le 11/02, et bien sa dépêche disparaît deux jours plus tard et c'est très frustrant. Et je le sais, parce qu'une de mes dépêches a été publié le 12/02.

Et je ne parle même pas des journaux. Parce que même s'ils n'apparaissent pas sur la page principale, pour ceux qui vont les lire et les commenter, ça prend du temps aussi, donc il faut les prendre en compte, parce que les journées n'ont que 24h et le temps de moulage sur linuxfr est probablement une durée fixe. Si je reprend le cas de ma dépêche, dans les 2h qui ont suivi sa publication, on a vu 3 journaux qui sont à plus de 100 commentaires dont 1 à plus de 200 (merci systemd). Bon, c'est un coup de pas de bol, mais voilà, il faut bien comprendre que ça freine l'écriture de dépêche de qualité : pourquoi se faire chier si tout ce travail disparaît en quelques jours dans les oubliettes de linuxfr ?

Actuellement, je suis en train d'écrire le prochain épisode de ma saga sur les jeux vidéos. À la louche, je dirais que j'y ai passé déjà une dizaine d'heures en cumulé (c'est vraiment un gros épisode, pour les autres, j'étais plus autour de 3-4h). S'il disparaît en quelques jours, je vais être un peu déçu. Bon, ça ne m'arrêtera pas, mais voilà, ça fait chier.

Écrire une dépêche avec du contenu intéressant, ça prend beaucoup de temps. Vraiment beaucoup de temps. Donc trouver une solution pour que ces dépêches puissent être plus visibles, c'est vital. Parce que quand on voit qu'on disparaît au profit d'une annonce de LUG ou de la revue de presse de l'APRIL qui reçoit très rarement plus de 1 commentaire, on se sent un peu rageux.

Ha mais on peut continuer à critiquer le goto. Je suis tout à fait d'accord que son usage se justifie dans quelques cas bien identifié (grosso modo, les codes au cheminement complexe, comme les cas d'erreur du journal ou encore les parseurs), mais dans tous les autres cas, on a inventé des structures pour cacher les goto et avoir une sûreté supplémentaire, généralement parce qu'on a une portée (scope) différente et donc, on a des garanties sur la durée de vie des variables et tout ce genre de chose.

Pour moi, on pourrait continuer à inventer des structures pour les cas restants. Le goto fait partie d'une ancienne boîte à outils qui n'est plus guère compatible avec les techniques modernes. Si on prend juste le fait de déclarer les variables au plus près de leur première utilisation, c'est compliqué avec des goto, parce qu'on n'a pas le droit de passer par dessus une déclaration de variable.

Pas break qui sert déjà à trop de choses (imagine que tu veuilles lancer une "exception locale" comme je décris au milieu d'une boucle, et bien ça ne marchera pas). Et goto, ben heu, voilà quoi.

Retrouver une syntaxe proche des exceptions ne me choquerait pas, mais ça ne serait pas possible pour ne pas casser la "compatibilité" entre C et C++. Si je devais vraiment me creuser la tête, je proposerais peut-être check (pour try), fail (pour catch), discard (pour throw).

Surtout que la gestion des exceptions en c++, c'est loin d'être gratuit.

Tout dépend de ce que tu appelles gratuit. Si c'est à l'exécution, si, c'est gratuit sur pas mal d'architecture. Si tu parles en terme de maintenance, c'est pas pire qu'autre chose et parfois, c'est plus simple (dans le cas de parser par exemple, où on peut arrêter à n'importe quel moment).

Sur la plupart des architectures, les exceptions sont gratuites au sens où il n'y a pas de code supplémentaire qui est exécuté si aucune exception n'est levée. Et pour les autres, ça utilise setjmp/longjmp donc je dirais plutôt que les exceptions sont imbattables en C++.