rewind a écrit 3413 commentaires

Où donc ?

Ici. Où tu dis d'ailleurs qu'il ne faut pas dénigrer les autres, or c'est exactement ce que tu fais avec Phonon.

Si le grand public ne le fait pas, je n'ai pas à vouloir le faire, c'est ça ? Pour être cohérent, il faut alors supprimer le tiling de Kwin, ça m'étonnerait que le grand public s'en serve des masses.

KDE n'a jamais prétendu être grand public uniquement. C'est à toi d'être cohérent.

Est-ce que ça suffit pour dire que la «partie multimédia (de KDE) laisse considérablement à désirer…» ? Je ne crois pas non.

Un exemple tout bête : tu ne peux pas ouvrir une vidéo avec Phonon par SMB ou SFTP sans télécharger le fichier localement.

C'est vrai que le grand public (puisque c'est la cible que tu désignes un peu plus haut) ouvre des vidéos de 1Go par SFTP tous les jours… C'est juste une blague ton argument.

Au delà de la question des sous, je pense que vous vous y prenez mal. Vous arrivez avec un concept complètement ficelé, et vous cherchez juste un gars qui va pisser du code. D'après la description, il n'y aura pas beaucoup de marge de manœuvre pour modifier le concept du jeu. Du coup, ce n'est pas très motivant, ça crée un déséquilibre entre l'éventuel codeur et vous, les artistes. Après, souvent, c'est dans le sens contraire que ça se passe, un codeur va chercher des artistes avec son concept ficelé et veut juste des mains pour dessiner ce qu'il veut. Si vous voulez un codeur, il faut pratiquer la coopération et la co-élaboration. Sans ça, ce sera dur à mon sens.

Oui, c'est sur http://www.charabia.net/ ! Je m'en suis servi il y a quelques temps, c'était très pratique et les essais philosophiques sont à mourir de rire. L'outil est en GPL et c'est bien du Java.

Ça, c'est la question piège ! Et honnêtement, je n'ai pas de réponse. Je n'ai pas vu d'autres applications des systèmes à entités que dans les jeux vidéo. Après, pour un site web, j'ai un doute sur l'application directe. Je pense qu'il faut adapter le concept, notamment par rapport à la base de données (qui va contenir les composants). Mais je n'ai aucun pointeur à donner.

Un simple test par rapport à la borne supérieur et à la nullité est suffisant, c'est souvent beaucoup plus efficace.

Surtout dans ce cas où la taille du tableau est connue à l'avance puisque c'est une constante.

C'est l'ordre dans le quel tu les enregistre dans le manager qui définit l'ordre d'appel. Ensuite c'est l'appel du preUpdate() de tous les systèmes, puis de update(), puis de postUpdate().

Pas exactement. Le constructeur de System prend en paramètre une priorité et, comme indiqué dans la doc, les systèmes avec une priorité petite seront exécutés les premiers. Dans le Manager, ça se traduit par un tri suivant la priorité avant l'initialisation de tous les systèmes.

Je crois que c'est comme ça que fonctionne Boost.Pool. Et oui, c'est une bonne idée pour allouer les composants. Après, comme toutes les entités n'ont pas tous les composants, tu auras sans doute plein de cases vides. Donc, je ne suis pas persuadé que ça soit si bien que ça. Actuellement, la lib utilise un std::set pour avoir la correspondance entre une entité et son composant, parce que c'est à l'utilisateur d'allouer ses composants comme il le souhaite. Après toutes les discussions qui ont eu lieu ici, je vais sans doute réfléchir à faire l'allocation des composants dans la lib.

Il ne faudrait pas que le destructeur et les méthodes faites pour être surchargées soient déclarées virtual ?

C'est bien le cas.

Je vois que tu ne les définis comme virtuels que dans les classes filles

Non, dans System, j'ai bien un destructeur virtuel et les méthodes init, preUpdate, update, postUpdate qui sont virtuelles. Après, dans le .cc, tu n'es pas obligé (et même je crois que c'est interdit) de mettre le mot-clef virtual. Ce qui compte ici, c'est bien le .h et dans le .h, c'est bien virtual.

Typiquement, le lien entre les deux composants va se faire dans un système (qui va gérer l'animation si je comprends bien). Ton système va considérer toutes les entités qui ont à la fois Animation et Modèle, et donc tu auras accès au deux pour déterminer quel est la bonne frame dans l'animation. Normalement, dans Animation et Modèle, tu n'auras que des données et rien d'autres.

Sans doute mon traumatisme sur mes cours de mécanique quantique (pas du tout essentiel mais il est obligatoire pour un diplôme d'ingé pour dire qu'on a un peu de théorie universitaire, et très très ennuyeux).

L'autre fois, j'ai entendu quelqu'un qui disait qu'à l'école, on n'apprenait que des choses qui ne servaient à rien. Et je partage tout à fait cette analyse. Effectivement, la mécanique quantique ne t'a jamais servi, comme à 99% de ceux à qui on l'a appris. Tout comme la philosophie en terminale, tout comme plein d'autres choses. Mais le but de l'école, c'est de former des citoyens capables de comprendre et d'appréhender le monde qui les entoure, y compris dans leur travail, mais également quand il faudra débattre et trancher des sujets de société. Avoir appris la génétique, ça ne fait pas de moi un généticien (tout comme ton cours de mécanique quantique n'a pas fait de toi un chat de Schrödinger), mais ça permet de comprendre quand on parle d'OGM.

Un étudiant qui fait ça, c'est un bon étudiant! Ben oui, c'est un étudiant qui sait chercher ce qu'il faut pour répondre à la demande de la manière la plus rapide possible, il sait chercher, réutiliser (le libre n'est-il pas la réutilsiation de ce qu'on fait d'autres?)

S'ils faisaient les choses de manière intelligente, oui ça irait. Mais ce n'est pas comme ça que ça se passe. Le workflow de l'étudiant feignant, c'est : je tape un mot clef sur Google, je vais sur la première réponse (qui vient souvent du Site du Zéro), je copie colle, je compile, et si ça marche pas, je recommence avec la deuxième réponse, etc.

Après, si l'enseignant demande une chose qu'on peut copier-coller, ben c'est son choix…

Gérer une liste chaînée, par exemple, tu peux trouver à peu près un millier d'implémentation sur le web, il n'empêche qu'il faut l'avoir pratiqué au moins une fois dans sa vie pour bien comprendre comment ça fonctionne. C'est ce qu'on demande à nos étudiants, ce n'est pas la mer à boire.

Toi, ça fait longtemps que tu n'as pas mis les pieds dans une université. Déjà première chose, les «universitaires» sont généralement ceux qui travaillent à l'université, pas ceux qui y étudient qu'on appelle plutôt «étudiants».

Il reste certes le domaine de la recherche ainsi que celui de l'enseignement, mais voila, il faut être clair la dessus (et être clair qu'il y a moins de places pour le boulot de ce type que de places d'université).

Moi je suis très clair là dessus : l'université fabrique et transmet le savoir, elle n'a pas vocation à former des salariés prêt à l'emploi. Cependant, il y a des filières dites professionalisantes (Licence Pro) qui ont cette vocation (et qui le font plutôt bien). Après, je considère que c'est aussi aux entreprises d'assurer une partie de la formation de leurs salariés, en particulier des jeunes salariés. L'université leur apprend les généralités, les entreprises adaptent les étudiants à leur cœur de métier. C'est une vue de l'esprit assez simpliste de croire que l'université pourrait former à des métiers vu la quantité de métier disponible. Rien qu'en informatique, il y en a une tétrachié. Donc, on donne à nos étudiants une formation qui leur permet par la suite de continuer à se former tout seul ou dans leur entreprise parce qu'on leur aura donné les bases essentielles et la théorie nécessaire pour comprendre la mise en pratique.

bon, il me semble quand même que depuis quelques temps, les IUT et IUP permettent de parler plus de la pratique, ça va mieux la dessus.

Les IUP sont en train de tous disparaître (en gros depuis la réforme LMD) et une grosse majorité des étudiants d'IUT va ensuite… à l'université ou dans des écoles d'ingénieurs. C'est fou hein !

La théorie est essentielle (pour certaines professions), mais ce n'est pas incompatible avec le fait qu'elle soit ennuyeuse. Je ne vois pas pourquoi tu opposes ces deux mots.

Je ne vois pas pourquoi la théorie devrait être ennuyeuse et la manière dont l'expression est employé dans l'annonce a quelque chose de très péjoratif, un peu comme ton discours.

En lisant l'annonce du changement de nom, il y a un passage que je n'ai pas du tout aimé.

L’esprit des cours ne change pas : on doit pouvoir apprendre en s’amusant, sans prise de tête et sans théorie ennuyeuse. C’est absolument essentiel à nos yeux. Nous pensons même que nous sommes capables de faire entrer cet état d’esprit qui vous plaît au sein des écoles et des universités !

La théorie n'est pas ennuyeuse, elle est essentielle si on veut comprendre ce qu'on fait, et pas juste appliquer les recettes du Site du Zéro d'OpenClassrooms. Et les universités n'ont pas besoin qu'on leur apprenne comment transmettre le savoir ! Les écoles non plus. Je n'aime pas du tout cette manière de voir les choses et de dénigrer l'enseignement supérieur.

Ce site constitue pour moi une référence pour apprendre a programmer facilement. Certain critiqueront cette dernière phrase mais pour moi qui ai majoritairement appris par moi-même ce site a été un formidable tremplin.

Je dirais que sur le Site du Zéro, on trouvait tout et son contraire et le pire côtoyait le moyen, voire de temps en temps le bon. Pour un enseignant en informatique, le Site du Zéro, c'est une plaie, c'est la source d'approvisionnement préféré en copier-coller des étudiants feignants.

Il y a d'ailleurs de fortes changes que j'utilise ta librairie ;)

N'hésite pas à faire remonter tes besoins pour l'améliorer !

Je trouve ça quand même dommage, pouvoir passer à un rendu console ou 3D facilement, c'est chouette :)

Oui, mais tu vois, tu n'auras pas les mêmes besoins pour chaque rendu. Entre un ou plusieurs caractères pour le rendu console, un sprite pour le rendu 2D et un modèle 3D pour le rendu 3D, si tu dois définir et sauvegarder les trois en permanence, tu en as deux inutiles en permanence. Et il y a certainement d'autres choses à prendre en compte : les collisions en 2D et en 3D, c'est pas exactement pareil. Donc, ce n'est pas juste une histoire de rendu, ça peut avoir une influence. Après si on reste dans un seul domaine, genre en 2D ou en 3D uniquement, là, on pourrait sans doute faire des choses, mais est-ce bien utile ?

Justement, ça fait pour moi partie du rendu. Et je pensais que c'était pas simple de séparer les deux actions en SFML mais ça fait quelque temps que j'y ai pas touché et tu as l'air sûr de toi donc ça doit être faisable. Juste que ça me parait overkill de séparer le rendu en deux systèmes, j'ai du mal à voir ce que ça apporte.

Pour moi, ce sont deux choses bien séparés. D'ailleurs, typiquement, tu as deux composants pour ce genre de chose et tu peux très bien imaginer des entités qui ont l'un et pas l'autre. Une entité qui a une position dans le monde mais qui est invisible (donc pas de position à l'écran), c'est assez courant. Et à l'inverse, des élements d'interface graphique qui vont avoir des positions sur l'écran mais pas dans le jeu (genre un score, un nombre de vie), ça existe aussi. Les deux sont nécessaires.

Ca va vite dans les jeux: les niveaux de Newton Adventure font 64x64 cases, soit déjà plus 4000 objets, alors qu'on est très loin de la taille des cartes d'un rpg.

Et combien d'objets «bougent», c'est-à-dire ont un mouvement ? Typiquement si tu fais la détection de collision à la main, pas besoin de croiser l'ensemble de 4000 objets (soit 16000000 de tests), il suffit de partir des quelques objets en mouvement (donc un sous-ensemble assez petit des 4000 objets) et de les croiser avec l'ensemble des 4000 objets. Et là, j'ai déjà un algorithme plutôt naïf qui permet de ne pas effondrer les perfs tout de suite.

en ce moment la mode est d'ajouter un éclairage dynamique sur des graphismes 2d classiques

Tu as des liens sur cette question ? Ça m'intéresserait de voir ça.

Tu bases tout sur SFML, ce que je trouve un peu dommage, pour moi un des avantages de ce paradigme c'est de séparer proprement le rendu du reste, pour pouvoir faire plusieurs implémentations du système rendu (Tu pourrais donc avoir une version SDL, une version SFML et une version console des mêmes balles rebondissantes en recodant uniquement le rendu).

Oui, j'utilise des classes de SFML (en fait une seule, Vector2f) par souci de simplicité. Je pourrais en effet recoder cette classe et faire une copie à chaque tour. Mais autant être simple et utiliser le bon type. Il me semble que ça ne sert à rien de se dire qu'on va utiliser plusieurs rendus quand on n'en utilisera qu'un seul. Oui, ça serait possible mais ce n'est pas un exercice qui m'intéresse plus que ça. Du coup, je m'autorise à reprendre des types de SFML.

Je saisi pas bien ce besoin d'avoir un composant avec les coordonnés réels, pour moi c'est interne au rendu, et donc le système rendu devrait directement travailler avec le composant position. En plus en SFML ce genre de chose se gère avec un viewport, ce que tu vas avoir du mal à faire si tu sépare rendu et traduction des coordonnés.

Au contraire, SFML gère très bien la traduction entre coordonnées de l'univers et coordonnées de l'écran grâce à une View. Dans l'exemple, j'ai fait la traduction moi-même mais c'était pour l'exemple. Après, on peut déléguer ça à SFML (il suffit juste de définir la View qui va bien).

Comme dit plus haut c'est triste cet entier à mettre à la main dans toutes les classes :-(

Meunon, ça s'automatise tout ça.

Ha, je pensais que tu utilisais Box2D. Du coup, je me suis trompé.

Ton exemple est un très bon cas d'étude. Il me rappelle un cas similaire sur Bomberman qui a des similitudes avec ton cas et duquel tu pourras sans doute t'inspirer.

Première chose : il n'est pas sûr que ton cas soit idéal pour utiliser un système à entités. Tu pourrais rester dans une conception classique et ça marcherait, je pense. Maintenant, on peut très bien utiliser un système à entité et je vais te dire comment je ferais.

Deuxième chose : tout ne se règle pas à coups de composants. Typiquement, le fond de carte n'est dans aucun composant, tu vas la dessiner en entier et ensuite, tu dessines le reste. Un autre classique, c'est la position du héros qui peut être dans un composant mais qui doit être accessible dans la plupart des systèmes.

Maintenant sur le fond, reprenons.

Du coup, j’ai la tuile (sol, eau ou mur en gros) qui est dessiné en premier, ensuite les mécanismes (interrupteurs, portes, pics qui sortent du sol à intervalle régulières…) et enfin les «objets» (je ne sais pas comment nommer cette catégorie: personnages, monstres, caisses…).

En fait, il n'y a pas vraiment trois couches, il y en a deux, voire une et demie. Tu as ton fond de carte (ce que tu appelles tuile et qui ne change pas normalement donc que tu dessines en une seule fois avant tout le reste, ça compte donc pour un demi). Ensuite, tout le reste, ça fait partie de la même catégorie, celle des objets du jeu, éventuellement avec un composant Collideable qui contient un champ height (comme dans l'exemple ci-dessus) qui va indiquer qu'est-ce qui est à quel niveau, ou level comme tu le dis après, c'est la même idée.

Au début je me disais que seul les objets pouvaient bouger mais maintenant, je veux avoir des mécanismes qui peuvent bouger par exemple. Du coup je me dis qu’un ECS ça pourrait être pratique: un composant «mécanisme», un composant «mouvement», un composant «objet» pour savoir si c’est un objet qui flotte ou non et savoir et une autre propriété du style, etc. Et même avec des spécialisations, genre certains mécanismes ne sont pas à mettre à jour automatiquement ne sont pas à mettre à jour automatiquement (portes et interrupteurs sont déclenchés par l’action du joueur mais les pics qui sortent puis rentrent du sol sont automatiques).

Ton début n'est pas mauvais. Je ne mettrai pas de composant «mécanisme», parce qu'un mécanisme, c'est une entité, pas une partie d'une entité. Il n'y a pas de données dans un mécanisme (sauf peut-être un type mais en fait, chaque type de composant va être défini par ses capacités, pas par un entier qui ne veut rien dire en tant que tel). Idem pour le composant «objet». En revanche, d'après ta description, tes entités mécanisme et objet vont avoir un composant Position. Ceux qui bougent auront un composant Mouvement indiquant l'amplitude du mouvement (on peut se restreindre à un mouvement soit horizontal soit vertical). Et tu auras donc un système qui prend toutes les entités avec une position et un mouvement pour mettre à jour la position en fonction du mouvement. Tu pourrais avoir un composant Ouverture pour l'entité interrupteur qui contient l'entité porte correspondante (ou même plusieurs entités si ça peut ouvrir plusieurs portes). Et donc, un système qui prend toutes les entités avec une position et une ouverture et qui va regarder la position actuelle du héros et ouvre la porte si jamais le héros et sur la même position que l'interrupteur. Pour tes pics, c'est un peu la même idée que pour mouvement, c'est le cas typique de l'animation. Donc tu vas avoir un composant Animation qui indique le nombre d'animation et la frame courante et les durées entre chaque frame. Ce composant, tu pourras le réutiliser pour d'autres mécanismes animés. Et pour les pics, tu peux avoir un composant Danger qui indique le type de danger (destruction, etc) et à quelle frame ils apparaissent. Tu auras un système qui va prendre les entités avec animation et danger pour dire si l'entité est actuellement en mode danger ou en mode pas danger, puis un système qui va prendre les entités avec danger et position, et qui va regarder si le héros est sur un danger ou pas et si ce danger est actif ou pas, et qui peut faire la même chose avec n'importe quel objet en fait et si ça fait mal, tu ajoutes un composant Lifetime (dont j'ai parlé à plusieurs reprises dans ce thread) qui indique que l'entité est morte. Ce dernier système va également fonctionner pour les danger pas animé. Et tu auras un système qui détruit toutes les entités qui sont mortes.

Après, avec cette conception, tu peux avoir des mix intéressants, genre des dangers animés qui servent aussi d'interrupteur (dans ton ancienne conception, je suis certain que tu n'y avais même pas pensé, ici c'est gratuit, il suffit de mettre les bons composants dans l'entité).

Le truc c’est que par exemple une IA (très basique) pour les monstres, c’est une méthode. Or j’avais compris que les composants ne stockaient que les données! Alors où se trouver la logique du jeu?

Non, ce n'est pas une méthode, c'est un système ! Tu auras un composant IA (avec ce qu'il faut pour que ça marche, par exemple fuite ou recherche pour savoir si l'entité fuit le héros ou le recherche) et ton système va prendre tes entités avec un composant IA et une position et va mettre à jour tout ça. Du coup, tu peux ajouter un composant IA à n'importe quel entité, montre ou même interrupteur, ou même porte (une porte qui fuit le héros, ça c'est fun).

Bref, en gros je pensais à un tableau en 3 dimensions pour stocker les tuiles, les mécanismes et les objets. Je mets à jour tout ce beau monde: automatiques + joueur + tout ce qui pourrait avoir été affecté par les précédents → ça évite que pour chaque case d’eau je vérifie si une caisse est au-dessus à chaque tour par exemple (je pense même à ne presque rien mettre en mise à jour auto et n’inscrire les caisses en automatiques que quand il y a déplacement par exemple).

Heu, à moins que tu aies des milliers d'objets (et donc des cartes énormes), je pense que c'est une optimisation prématurée. Quant au tableau, il est parfaitement inutile, sauf pour les tuiles (donc il est à deux dimensions). Tout le reste, ce seront des entités. Et la mise à jour se fait dans des systèmes. Je n'ai pas évoqué tous les systèmes mais tu auras un système pour les collisions par exemple.

Du coup grâce à cette technique je peux les dessiner dans le bon ordre, de sorte que les sprites qui dépassent sur la case du dessus ne soit pas dessinés en-dessous!

La manière dont chaque entité est dessiné et la logique du jeu sont deux choses séparées. Ton système de dessin va effectivement regarder toutes les entités avec un sprite et un level, peut les ordonner au préalable et les dessiner, mais quelque part, peu importe leur type, ça reste des sprites avec une hauteur.

Un entité conteneur de composant vs pas de conteneur et id pour connaitre les entités, quels sont les avantages et les inconvénients? J’aime bien la deuxième méthode mais ça risque de compliquer mon tableau à 3 dimensions! De toute manière, il va falloir faire attention que si un composant «meurt», tous les autres composants de l’entité doivent suivre. C’est pas très compliqué sauf si on fait des listes par composants (est-ce que la vue aurait chaque composant «vue» de chaque entité? Du coup la logique et la partie graphique du jeu auraient une méthode où on passe l’id de l’entité et qui détruit ses composants).

Du coup, tu peux choisir la deuxième, je t'ai donné des pistes pour supprimer ton tableau à trois dimensions. Pour la durée de vie des entités, tu peux regarder le tutoriel dont le parle, je donne une piste à base de composant Lifetime.

Si je modifie un composant j’aimerais bien pouvoir accéder à l’entité pour lui dire de mourir proprement, avec des composants à id on peut faire ça proprement. Ou alors ma super grille ne contient que des int qui sont des id!

Normalement, dans les systèmes, tu modifies des entités et tu accèdes à leurs composants. Donc tu as les entités correspondant aux composants. Et ta super grille, supprime la ! ;)

Pour les composants, j’ai l’impression qu’ils ont forcément une interface commune (au moins une méthode update), mais pas plus?

Non ! Ce sont des données, rien de plus. Le code de ta méthode update, il va dans un système, pas ailleurs.

N’est-il pas plus logique d’avoir un pointeur pour chaque type de composant qui est à null s’il n’en a pas?

Si tu as une entité container de composant, peut-être. Sinon, ça n'arrive pas puisque tu traites dans ton système uniquement les entités qui ont les bons composants.

Notamment parce que je ne vois pas l’intérêt pour mon jeu de rajouter des composants à la volée.

Pour l'instant non. Mais le composant Lifetime, tu peux l'ajouter à la volée, le composant IA, tu peux l'ajouter à la volée (en déclenchant le réveil du monstre avec un interrupteur invisible !). Bref, je vois plein d'extension facile avec les quelques composants que j'ai décrit.

Du coup il va falloir que je fasse de l’héritage sur les composants, j’ai l’impression à lire çà et là des trucs sur les ECS que c’était «mal»!

Oui, saimal ! Si tu hérites tes composants, c'est qu'en fait, tu as deux composants : un avec les données de la classe mère et un avec les données de la classe fille (sans les données de la classe mère). Ou alors, tes composants ne sont pas assez atomiques. Ou alors, tes composants sont mal faits.

Est-ce que je pourrait avoir un exemple très basique d’implantation de mon concept (en pseudo-code ou C++/Java/Python/…)? Parce quand c’est les concepts des autres j’ai du mal à suivre… Là je pense (j’espère) que ça m’aiderait carrément.

J'ai fait ce que j'ai pu, j'espère que ça t'aura éclairé. Je te conseille vraiment d'aller voir l'exemple donné au début (et aussi de suivre le lien donné au début de l'article).

Quand je disais pas trop mal foutu, je pensais en particulier aux VertexArray qui permettent justement ce que tu dis (deuxième point).

En opengl, ce qui coute cher, c'est le changement de contexte[1]. Typiquement changer la texture, le mesh ou le program (shader) courant (Il faut tj se rappeler qu'opengl est une machine à états, qui plus est distante car sur la carte graphique). La difficulté sera d'ordonner les rendus pour limiter ces changements (La vrai difficulté sera quand des objets partageront certaines textures et d'autres partageront certains mesh, le tout de manière non homogène. Faut-il limiter les changements de texture ou les changements de mesh ?).

Je fais confiance à SFML pour ça. Il y a des trucs dans SFML qui me font dire que c'est bien foutu à ce niveau là. Ou plutôt pas trop mal foutu.

Pour le moteur physique ce sera comment gérer l’interaction entre les éléments. Typiquement, pour ton exemple des balles rebondissantes, comment rajouter les collisions entre les balle ? Comment trouver les balles proches de celle actuellement traitée sans parcourir toute la liste ?

Je crois que je vais étendre ce petit tutoriel pour montrer comment on fait : on utilise ce qui marche déjà. En l'occurrence, des moteurs physiques 2D, il n'y en a pas 50 et on tombe très vite sur un qui est très utilisé (je crois d'ailleurs que c'est celui qui est utilisé dans Newton Adventure). Je crois que ça fera partie d'un de mes prochains articles de la série.

Une des optims qui était prévu était de faire le rendu en deux passes :

• Une première classique qui parcourrait les entités dans l'ordre où elles viendraient. Par contre au lieu de faire le rendu directement, elle remplirait une liste de "commande d'affichage" (mesh, program, texture, … à utiliser)
• La deuxième, trierait cette liste pour limiter les changements de contexte et ferait le rendu réelle en parcourent la liste triée.

C'est une technique intéressante, j'y réfléchirai le moment venu.

En tout cas, ça fait plaisir de voir tes commentaires qui mettent un peu la pression ;) N'hésite pas à continuer.