jlgrall a écrit 26 commentaires

J'ai préféré changer le nom du projet pour éviter les conflits avec d'autres projets. (Le mot "entity" est trop général)

Je l'ai donc rebaptisé esEngine, pour Entity System Engine.

L'adresse: https://github.com/jlgrall/esEngine

Non pas du tout. Je pense que c'est ton propos qui déformait ces idées d'origine en l'exagérant. Mais je comprends ce que tu veux dire. Dans le fond, nous somme quasiment d'accord, à part que je ne pense pas utile de limiter artificiellement JS, mais qu'il serait bien plus intéressant de pousser une bonne alternative.

+1

Oui, mais ça ne te dit pas quel script sur quelle page en est responsable.

(Désolé pour le post précédent.)

Les web workers permettent de faire du parallélisme en JavaScript sans danger grâce à une forte séparation entre les contextes d'exécution.

Tu ne peux pas accéder aux données d'un autre contexte, il n'y a donc pas de risque d'interférer. La seule façon de transférer des données était de les passer sous forme de chaînes de texte ou d'objet JSON qui seront clonés. Il existe maintenant la possibilité de passer un ArrayBuffer (tableau de nombres) qui ne sera pas cloné, mais transférés d'un contexte à un autre, comme s'il disparaissait du premier contexte. C'est plus rapide, car cela peut se faire sans copie de mémoire, mais ça ne fonctionne pas sur tous les navigateurs et ça demande plus de travail qu'un simple JSON.

Tu as accès à la plupart des fonctions de base de JavaScript pour faire tes calculs (Array, Object, Math, setInterval(), …). Tu as aussi accès aux fonctionnalités réseau et peut donc envoyer/recevoir des données au serveur. Par contre tu n'as pas accès au DOM. Il te faudra envoyer des messages au thread GUI (le thread principal de la page web qui a créé les web workers) qui se chargera de manipuler le DOM.

Les web workers sont donc souvent utilisés pour faire des longs calculs sans bloquer le thread GUI et pour traiter les entrées/sorties avec le serveur.

Je te conseille la documentation de Mozilla Developer Network (MDN) qui offre souvent les meilleures informations:
https://developer.mozilla.org/en-US/docs/DOM/Worker
https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers

Quant aux erreurs à éviter et aux limites, je n'en ai pas en tête, si ce n'est bien vérifier la compatibilités des différentes fonctionnalités avec les navigateurs (ça se trouve en bas des pages sur MDN).

Et pour ceux qui n'auraient pas un OS correct, on fait ça avec n'importe quel Arduino ou Rasp Pi. Pour tout le reste, il y a jslinux.

Bon là, ça vire carrément au HS. J'arrête.

C'est vrai que quand on utilise NoScript, et les bloqueurs de pub, on se rend moins compte de la lourdeur des pages web. J'ai pas un ordi spécialement puissant et pourtant j'ai souvent plusieurs dizaines d'onglets ouverts dans plusieurs fenêtres sans problème.

Ok, vous avez tout à fait raison pour la minification du JavaScript. Il y a des déminificateurs, et des beautifiers de code, mais si on veut, on peut facilement rendre un code complètement illisible. Ca n'empêche pas de pouvoir suivre les connections réseau par exemple.

A mon avis, ce qui va plutôt se passer, c'est un transfert d'une partie des calculs des serveurs aux clients afin d'économiser sur les serveurs.

Ce n'était qu'une prédiction personnelle, pas un jugement sur ce qui serait mieux ou pas. Mais bon dans le contexte, c'est pas forcément compréhensible :)

Dans l'absolu, je ne suis pas contre le transfert de calculs vers les clients. Déjà, vu que ça se fait dans une sandbox, les risques sont limités, ce qui n'a jamais été le cas avec Flash par exemple. Ensuite, avec des technologies comme WebRTC, ça permettrait de faire des applications décentralisées (faudra quand même du temps pour y arriver), chose que j'ai toujours soutenu.

Il y a aussi des applications intéressantes comme gmail, ou ownCloud que je vais tester très bientôt, et qui ne pourraient pas fonctionner sans JavaScript car ce serait trop lent et mal intégré.

Après, dire qu'il faut pas rendre JS plus rapide car JS ça bouffe du CPU, c'est pas très cohérent. Par contre, en avoir marre du JS utilisé n'importe où, n'importe comment, c'est beaucoup plus pertinent à mon avis. Moi aussi quand je lis un article, je déteste avoir des trucs qui bougent partout, et du code qui s'exécute par derrière et que je soupçonne de ne pas vraiment aller dans le sens de mes intérêts. Et malheureusement la seule solution qui marche à peu près à l'heure actuelle est NoScript. C'est dommage que tout le monde ne fasse pas comme moi des pages qui puissent s'afficher correctement avec ou sans le JavaScript :(

La situation du JavaScript ne me satisfait pas complètement: elle m'oblige à tout le temps faire des compromis…

Au moins avec JavaScript, on peut facilement lire le code source et tracer les connexions réseau. De plus les navigateurs permettent de suivre de plus en plus facilement les ressources utilisées par chaque site ouvert.

A mon avis, ce qui va plutôt se passer, c'est un transfert d'une partie des calculs des serveurs aux clients afin d'économiser sur les serveurs. Tout en gardant la supervision sur les serveurs afin de contrôler les données et d'enregistrer les activités des utilisateurs.

Cela n'empêchera pas les utilisations malveillantes et le vol de temps de CPU, mais je pense que ça restera marginal. Dans le cas contraire, il faudra que les éditeurs de navigateurs ajoutent plus de contrôle. Mais je le répète, je pense pas qu'un tel réseau puisse se mettre en place à grande échelle ou sur des grands sites sans être repéré.

Ton lien est intéressant, il montre un exemple où l'utilisateur choisit de participer aux calculs. Mais je me demande s'il existe des cas où une utilisation malveillante sans avertir l'utilisateur a été détectée, et quels sont les résultats.

Je travaille justement sur l'implémentation en JavaScript d'une architecture logicielle qui est par définition optimisée pour l'exécution en parallèle de plusieurs processus (entity.JS). Malheureusement les web workers ne sont vraiment adaptés qu'à des tâches travaillant sur des données disjointes ou dont le coût du transfert de données vers les web workers et retour, est inférieur aux coûts en calculs. Des améliorations dans ce domaine seraient donc très bénéfiques.

Ne donnes pas de mauvaises idées… C'est sûrement faisable.

Wow :)

Après un rapide coup d'oeil aux sources, je me demande si c'est beaucoup plus lourd que des images normales, des sprites et du JavaScript pour animer.

En tout cas, c'est intéressant.

https://github.com/jlgrall/entity.JS

Au fait, les nanims en JS, ça donne quoi ? :)

Merci. En fait, c'est la première fois que je commence vraiment par la documentation. Souvent en javascript la seule doc que j'écris c'est le code…

T'inquiètes pas, je reviendrai faire du bruit par ici quand il y aura un peu plus de contenu.

A part ça, si c'est possible de lire ton code quelque part, ça m'intéresse pour voir comment tu utilises l'architecture ES, comment tu initialises ton jeu et comment tu intègres l'ES et son environnement par exemple.

Est-ce que quelqu'un a essayé de monter un serveur LDAP pour l'utiliser avec ownCloud ?

Avec des amis, nous aimerions beaucoup avoir un serveur LDAP ainsi que plusieurs services utilisant ce serveur: accès ssh, vnc, nx, ownCloud, un vpn, un wiki, une gallerie de photos, etc. Avec la possibilité de gérer pour nos familles et amis, qui peut se connecter à quel service, qui utilise combien de place, etc. Tout le monde serait très intéressé et voudrait transférer ses comptes par exemple depuis DropBox ou ses photos pour les partager dans la famille.

Comme je suis sur Mageia, j'avais posté des questions sur leur forum avec une description précise de l'architecture voulue: https://forums.mageia.org/en/viewtopic.php?f=8&t=4311 Mais ça a l'air très compliqué.

J'ai essayé de trouver des solutions pour facilement installer et administrer un serveur LDAP, mais ça me semble très difficile et je n'ai rien trouvé pour l'instant. Cette semaine, j'ai commencé à lire un livre "The ABCs of LDAP" (400 p.) trouvé à la bibliothèque dans l'espoir de mieux comprendre LDAP.

Donc si quelqu'un connaît une solution plus ou moins facile à installer, qui permet de gérer les utilisateurs avec une interface graphique et qui permet aux utilisateurs de s'enregistrer et changer leurs mots de passe, ça m'aiderait beaucoup.

Effectivement expliqué comme ça, ça a l'air pareil. On peut tout à fait modéliser un ES dans un langage POO. Est-ce que dans ton cas, tu as une vraie séparation de la logique et des données ? Comment fais-tu pour modifier le comportement de ton modèle ? Comment sont stockés les objets du "modèle" ? Est-ce que le type du modèle est défini par le modèle ou uniquement par ses objets, ce qui permet de transformer un modèle en n'importe quel autre en changeant ses objets ?

Sinon, tu peux essayer de lire http://www.richardlord.net/blog/what-is-an-entity-framework Peut-être que ça t'aidera à mieux voir les subtilités entre des architectures qui paraissent proches ?

J'ai mis le brouillon sur framapad exprès pour qu'on puisse y ajouter tous les commentaires voulus.

Apparemment quelques personnes ne connaissant pas le concept des framapad (etherpad) font des tests et cassent les liens qui s'y trouvaient. C'est normal, j'ai fais ça aussi la première fois…

Donc tout spécialement pour ceux qui veulent découvrir framapad, je vous conseille d'aller voir ce lien: https://framapad.org/ puis soit de se faire un pad, soit d'utiliser le pad de test pour faire vos propres expériences. Vous verrez, c'est vraiment très pratique.

Veuillez m'excuser, j'aurai dû inclure ce message dans le journal.

J'ai donc rétabli les liens et ce qui était cassé. En plus je recopie les liens vers les brouillons ici:
- Design: http://lite.framapad.org/p/kQVEUslyvE
- API: http://lite.framapad.org/p/GhOo1ivlba

Je n'y avais pas pensé comme ça, c'était trop simple. Je garde l'idée merci :)

En fait, vu que l'update se fait moins souvent que le rendu, ça permet d'éliminer beaucoup de multiplications de matrices et donc d'avoir un rendu encore plus rapide.

Eh eh, oui c'est possible, par exemple si tu mets un jeu dans un jeu. Par exemple tu es dans un MMORPG et tu va vers une console et tu peux jouer à un jeux dessus.

Enfin bon s'est un peu tiré par les cheveux…

C'est pas mal pour l'update: les systèmes n'ont à s'occuper que des attributs local*

Par contre lors du rendu graphique, c'est plus compliqué. Lorsque le système de rendu graphique fait l'itération des composants Transformation, à chaque fois qu'il y a un parent, il devra passer par le parent. Donc les parents sont visités au moins autant de fois qu'ils ont d'enfants (et de sous enfants). En POO et OpenGL on commence toujours par les parents et on descend la hiérarchie en multipliant les matrices de position à chaque étape. Au final chaque objet n'est visité qu'une fois.

C'est vrai qu'en ES l'itération peut être optimisée car on peut mettre tous les composants dans un seul tableau à la suite, et donc le CPU peut optimiser les accès mémoire. Mais là on doit visiter tous les composants parents plusieurs fois, et je me demande s'il ne serait pas possible de faire mieux. Par exemple en définissant des composants TransformationEnfant et des composants TransformationParent, ou d'autres idées du même style. Car il ne faut pas oublier que les composants ne sont pas ordonnés, et donc l'itération avec un type de composant se fait dans le "désordre".

Revenons à ton exemple. Il suffirait de rajouter un boolean qui indique si les coordonnées world* ont déjà été recalculées à partir du parent, afin de limiter un peu le nombre de visites. A partir d'un enfant on ne remonterai alors plus que d'un niveau dans la hiérarchie, sauf si le parent n'a pas encore été recalculé. (Bon en fait au lieu d'un boolean j'utiliserai un int qui contiendrai un numéro incrémenté à chaque game loop, mais c'est pour l'idée). Pour l'instant, c'est un système de ce style que j'utiliserai.

Merci, je ne connaissais pas. Je vais peut-être contacter ce Chris Granger, ça pourrait être intéressant.

Ca m'a également permis de découvrir Light Table. Projet à suivre. (Malheureusement je ne connais pas ClojureScript, mais apparemment il va ajouter d'autres langages à son IDE)

L'architecture ES est en fait très simple, je pense même beaucoup plus simple à comprendre que l'architecture POO avec ses classes et ses objets. Elle est souple et très puissante, ça ne m'étonne pas du tout que ça puisse être utilisé ailleurs que dans des jeux, bien que je ne pense pas que ce soit adapté pour faire une des interfaces graphiques (GUI) par exemple.

D'ailleurs entity.JS permet de faire des ES, mais ce n'est pas spécifiquement orienté vers le développement de jeux vidéos. entity.JS peut être utilisé dans n'importe quel projet JavaScript tout en offrant de bonnes performances (notamment peu, voir pas de GC).

Juste une question. Qu'entends-tu par un ES récursif ?

qui n'est bien sûr que trop peu documenté.

Fallait commencer par la doc :P

Tu en es où dans Webcrise ? As-tu un lien ?

J'essaie de regarder le code de jeux implémentés avec un ES pour voir les besoins, les difficultés et trouver des idées. Donc si ton code est assez proche d'un ES, ça m'intéresse.

C'est ce que je pense aussi, mais il y a aussi parfois des contraintes externes.

L'architecture ES est relativement nouvelle, et il y a plusieurs façon de faire les choses. J'ai essayé de la présenter de façon pure dans ce journal, car c'est le chemin que je vais suivre pour entity.JS. Mais si tu va sur le wiki http://entity-systems.wikidot.com/ tu verra d'autres façons de faire.

En plus c'est un changement important de paradigme et les programmeurs ont souvent de la difficulté à ne pas remettre de la POO (Programmation Orientée Objets) dans leur code ES, même de façon inconsciente. Et ça m'arrive aussi :)

Souvent quand on essaie d'en parler, on se retrouve confronté à pas mal de résistance au début (et c'est normal). Voir cet article: Evolve your hierarchy du jeu Tony Hawk's Pro Skater 3, où l'auteur est amené à faire des migrations progressives vers l'ES.

C'est un plaisir.

Un des autres avantages de ES (Entity System), c'est que c'est beaucoup plus simple pour des non-programmeurs (graphistes, concepteurs de jeux, etc.) à comprendre et à modifier sans tout casser, car il n'y as pas besoin de se conformer à une structure de classes rigide et à sa hiérarchie. Tout est directement visible dans le code d'un système ou de quelques systèmes et facile à changer en cas de besoin. Dans la plupart des cas, il suffit de rajouter les composants voulus aux entités voulues et ça tourne.

Ca peut même se faire facilement en plein jeu, ce qui fait que la création d'un éditeur de carte par exemple est très facile et se base simplement sur l'interface de jeu normale. Ensuite pour enregistrer la carte, il suffit d'enregistrer les composants, ce qui correspond à un simple dump des composants dans un fichier. Pas besoin de sérialiser des objets, les données sont déjà sous forme sérialisée en mémoire :)

C'est un plaisir.

Un des autres avantages de ES (Entity System), c'est que c'est beaucoup plus simple pour des non-programmeurs (graphistes, concepteurs de jeux, etc.) à comprendre et à modifier sans tout casser, car il n'y as pas besoin de se conformer à une structure de classe rigide et à sa hiérarchie. Tout est directement visible dans le code d'un système ou de quelques systèmes et facile à changer en cas de besoin. Dans la plupart des cas, il suffit de rajouter les composants voulus aux entités voulues et ça tourne.

Ca peut même se faire facilement en plein jeu, ce qui fait que la création d'un éditeur de carte par exemple est très facile et se base simplement sur l'interface de jeu normale. Ensuite pour enregistrer la carte, il suffit d'enregistrer les composants, ce qui correspond à un simple dump des composants dans un fichier. Pas besoin de sérialiser des objets, les données sont déjà sous forme sérialisée en mémoire :)

Pour un moteur 3D ça semble bien. Je suis en train de regarder la doc. Faudrait faire une interface entre les objets de Three.js et les composants de l'ES, mais peut-être qu'on peut utiliser Object.defineProperty() dans les composants avec des setters qui écrivent directement les données dans les objets de Three.js. Cela pourrait être pas mal, à défaut d'un vrai moteur 3D implémenté en ES :)

Par contre il y a une chose sur laquelle j'ai encore plein de questions. Comment représenter une hiérarchie d'objets avec des composants qui par définition sont stockés dans une structure plate et non ordonnée. Par exemple, comment implémenter un scenegraph avec des composants qui permet d'avoir des sous objets dont la position dépend d'un objet parent ? Concrètement, le bras d'un personnage dépend du personnage, il suffit de bouger le personnage et toutes les parties du corps sont automatiquement à la bonne place.