Trop facile. Sauf pour les gens qui refusent la chose pour une autre raison qu'ils ne veulent pas reconnaitre. Reste à savoir ce que c'est… Moins avouable?
C'est sur ce genre de phrase que tu casses tout le débat. Tes idées ne sont pas stupides, elle ne sont simplement pas obligatoirement en accord avec tout le monde et elles méritent d'êtres discutées.
Mes ce genre d'attaques Ad hominem et autres positions extrémistes décrédibilisent beaucoup de ton propo.
Je souhaitais juste souligner que ton modèle de société est centré sur ta personne car tu souhaites que tout le monde profite de sa propre famille ou entourage sauf ceux qui servent à rassembler les gens car eux tu comprends, ils n'ont pas d'entourage.
Bref ton modèle de société est incohérent et ne fonctionne qu'autour de ta personne.
Tu apprendra que je n'ai ni femme ni enfants. Je suis célibataire et ma famille habite à 900km de moi.
Je ne travaille pas le dimanche. Par contre j'ai des amis qui sont en milieux hospitalier qui font des gardes le dimanche ou les nuits. Des gens de ma famille sont régulièrement d'astreinte le dimanche (c'est super cool quand je vais les voir le we et qu'on ne peut pas quitter la ville).
La société que je décrit (qui n'est pas obligatoirement mon choix) est celle qui existe depuis longtemps (et oui, ça peut être amener à changer). Les gens qui travail le dimanche font partie des exceptions. Et ça ne doit pas ce généraliser. Si c'était le cas ça ne serait pas la même société. Et c'est pourquoi il y a un débat. Vous prenez les gens pour des imbéciles quand vous niez ce changement de société et réduisez le débat au choix individuel.
Pendant 2000 ans, le mariage homosexuel était interdit. C'était pour des raisons différentes de maintenant mais ça était. Généraliser le mariage aux homos, c'est tirer un trait sur un point important de notre modèle de société.
Tiens, ça me rappelle quelque chose…
Tout à fais, et tu as raison. La société peut évoluer (et doit évoluer). Travail dominical ou mariage homosexuel sont des choix de sociétés pas des choix individuels.
C'est ce point que je critique, pas le travail dominical ou le mariage homo en eux-même.
Je ne dit pas qu'il n'est pas possible de tirer un trait dessus. Je dit que c'est un choix de société et que quelque soit le choix, ce choix est imposé à l'ensemble de la société.
Vous pouvez parler de liberté individuel, c'est un argument qui ce tient. Mais vous ne pouvez pas dire que vous n'imposez rien aux autres.
Non, avec ton modèle les gens peuvent trouvé du temps commun avec leur proche et faire des trucs avec eux.
Ce n'est pas un temps commun pour la Société (avec un grand S)
Je ne défend pas ma petite vie familiale (j'en ai pas). Je ne défend pas le modèle de société actuel. Je mets juste en avant que le problème ce n'est pas la liberté individuel, le salaire double ou la création d'emploi.
Pendant 2000 ans, la société (pas les gens) a eu un jour "commun". C'était pour des raisons différentes de maintenant mais ça était. Généraliser le travail le dimanche, c'est tirer un trait sur un point important de notre modèle de société.
Autant je suis pour le mariage homosexuel. Autant j'ai grandement regretter que les opposants au mariage homosexuel soit systématiquement ramener à des cato de droite réact et homophobe.
C'est très bien pour casser le débat dans l'oeuf mais ça ne fait pas un débat de société. Et ça réduit grandement la "victoire" du mariage homosexuel imposé de force et sans réelle débat sur les changements de société que ça inclue.
Toi, tu es contre la peine de mort, à part pour les pas gentils… Mais on appelle ça encore être contre la peine de mort, hein.
Tu sera gentils de ne pas me préter des idées que je n'ai pas et pour lesquelles tu n'as aucune idée de mon point de vu. Ça améliorera le débat.
PS : c'est quand même du foutage de gueule de dire "passer en famille" en demandant aux autres de gérer ta petite vie de famille… Hors besoins premier,s si tu enlève Bricorama, tu dois en toute honnêteté enlevé tes plaisirs égoistes, ils n'ont pas de priorité sur les plaisirs de autres. Egoisme quand tu nous tiens…
Pour info, je m'interdit d'aller au magasin le dimanche. Je vais au ciné en semaine. Le dimanche je le passe chez moi ou avec des amis (transport en voiture)
Je n'ai jamais dit si j'était pour ou contre le travail le dimanche, j'ai juste essayé de recentrer le débat sur ce qui me semble important : le temps commun. Sujet que tu t'es empressé d'éviter au nom de la binarisation des idées.
Mince, les britanniques, les suédois, les italiens et autres peuples ne vivent plus car ils travaillent le dimanche. Leur société s'est effondré à cause de ça.
J'en ai rien à foutre des autres sociétés. Je te parle de la société dans laquelle je vie et dans laquelle le débat a lieu.
Tu es pour des horaires d'ouverture uniques, des congés avec une date imposée et autres ? Car là on ferait plus de trucs en communs.
Et tu fais quoi des ciné, resto, petits commerces et autres ouverts dimanche (partiellement ou totalement), on supprime aussi ? On laisse faire ?
Si tu aurais lu mon commentaire en entier tu aurais pu lire ceci :
Oui, il y a des exceptions, oui il doit y en avoir mais ça doit rester des exceptions. Ces exceptions ne doivent être que les besoins premiers (santé, énergie) et pour des activités liés à cette vie commune : voir des amis (cinéma, resto, bar), faire la fête (boite de nuit), faire du sport (club de sport), partir en we, voir la famille (transport), …
Le problème du travail le dimanche est avant tout un problème de société. C'est un choix de société et pas un choix individuel.
Le problème n'est pas vraiment de savoir si le travailleur du dimanche est volontaire ou forcé et si il sera payé le double ou pas. (Enfin, ce sont des problèmes mais pas les plus primordiaux)
Lorsqu'on vie en société c'est avant tout vivre ensemble avec des règles communes et "fonctionnements" communs. Avoir les mêmes rythmes de vie.
Le dimanche chômé n'a plus grand chose à voir avec la religion. Le but est d'avoir un jour commun où la société se dit : "stop, nous avons un jour où l'ensemble des gens peuvent se voir". Le fait que ce jour soit le dimanche est certes un conséquence du christianisme qui avait instauré ce jour comme jour de communion mais il ça n'a plus rien a voir maintenant, l'important est que ce soit un jour commun.
Autorisé le travail le dimanche (vraiment, pas juste donner des exceptions) c'est cassé cette règle commune. C'est donc une atteinte à la vie commune, à notre société. C'est quelque chose d’extrêmement important qui mérite vraiment un débat (et pour les bonnes choses, pas pour des questions de salaires). C'est une évolution de la société qui doit être décidée ensemble et qui ne peut pas (juste) se justifier par des libertés individuelles.
Quand vous parlez de libertés individuelles pour justifier le travail le dimanche avec la liberté de choisir son jour de repos, à mes yeux, vous avez un discours asocial[1].
Le jour où il n'y a plus de jour commun de repos, il n'y a plus de vie commune. Certes les gens continuerons de voir leur amis. Mais quand organiser les activités communes qui s'étendent sur une journée si chacun a sa journée ?
Le but du dimanche jour de repos commun c'est la consolidation de la société autour d'un temps commun. C'est la même chose avec les horaires de travail journaliers : le soir, on ne travail pas (en général), on peut organiser un vie commune.
Oui, il y a des exceptions, oui il doit y en avoir mais ça doit rester des exceptions. Ces exceptions ne doivent être que les besoins premiers (santé, énergie) et pour des activités liés à cette vie commune : voir des amis (cinéma, resto, bar), faire la fête (boite de nuit), faire du sport (club de sport), partir en we, voir la famille (transport), …
Le fait que les gens puissent aussi le faire à d'autre moment n'est pas un argument valide pour le supprimer. Le but n'est pas que les gens aient du temps, c'est qu'ils aient un temps commun.
Pouvoir acheter sa plomberie le dimanche, oui, c'est sympa. Pouvoir être payer double parce que l'on travail le dimanche, oui, c'est sympa. Mais c'est un acte individuel. Est-ce que ça vaut ce changement qui touche à un fondement de notre société ? (C'est une vrai question, si ce n'est pas la question du débat)
[1] Dans le sens opposé à la société, je n'est aucun doute sur le fait que vous êtes sociaux, que vous voyez des gens, ..
Tu peux aussi filtrer sur le label de la partition, le constructeur/modèle de la clé, …
Après, si tu veux connaitre l'appartenance de n'importe quel périphérique inconnu, sans caractéristique particulière et branché sur n'importe quel port … il reste la caméra pour détecter qui branche le périphérique. (je te laisse le coder, ça devrait être facile :) )
udev (et donc systemd) permet d'avoir des règles spécifiques selon le périphérique (UUID). Je ne sais pas si la fonctionnalité est implémentée mais il ne devrait pas être trop difficile d'avoir un règle du type :
clé usb UUID "machin" => utilisateur toto.
D'ailleurs c'est peut-être ce qui est fait par goulou mais avec une règle sur le port USB plutôt que sur le périphérique.
Effectivement. Gtk doit aussi en avoir un. (Qt5 ne l'a plus).
Par contre c'est pas sur qu'ils l'utilisent et d'après les dev de Wayland (et donc Xorg) il semble que ça ne soit pas le cas. Et vu l’engouement des dev de toolkit à passer à Wayland, je pense qu'ils sont tous d'accord.
NX étant une surcouche au dessus de X11, on peut dire qu'il utilise X11, un NWayland serait moins efficace.
Non :)
NX par du principe que X11 n'est pas adapté au réseau. Il transmet les ordres X mais maintient un cache (dupliqué dans les deux proxys) de toutes les données.
Dire qu'un NWayland serait mois efficace est un peu rapide à mon goût : un diff d'image, de la compression et un système de cache ça réduit drastiquement le débit de donnée pour des applis classiques. Ça pourrait même être moindre que NX vu qu'il y a moins d'ordres à transmettre.
Certes, mais pour être efficace cela implique que les toolkits doivent parler 2 protocoles..
Les applis X qui passent par NX ne connaissent pas le protocole NX. Pourquoi les applis Wayland qui passent par NWayland devraient connaitre le protocole NWayland. C'est tout l'avantage d'avoir proxy qui fait la traduction.
Non: X11 'utilisé à l'ancienne' te fournit bien plus d'information pour un affichage distant efficace que Wayland!
Justement, il y a quasiment plus de toolkit qui utilise X "à l'ancienne" (à ma connaissance, dans les toolkits actuels (à défaut de modernes) il ne reste que Tk)
(relativement: X est loin d'être optimal) mais c'était de plus en plus rare
C'est pour ça que Wayland ne supporte pas le "network-capable". Il y a d'autres protocoles bien plus efficaces que X pour transférer des buffers et de moins en moins de projets utilisent X de manière "native".
Autant faire un proto local et utiliser les autres proto pour le distant. Si c'est bien intégré (ce dont je ne doute pas si on laisse le temps) ça équivaudra à un "ssh -W"
Donc si une aide (pas forcément régulière) t'intéresse s dis le moi…
Ne l'écoute pas rewind quelqu'un à peine capable de trouver le sujet de ses phrases ne peut t'apporter aucune aide digne de ce nom :)
Plus sérieusement, j'espère vraiment me tromper et que tu vas réussir. (Mais vraiment ! Je souhaite sincèrement avoir tort)
Mais voilà, quand je vois arriver quelqu'un qui annonce qu'il va faire un nouveau RPG avec une carte très très grande, de la génération procédurale, un monde ouvert, plein de quêtes et les derniers effets visuels à la mode et qu'en plus, il a pas d'expérience dans le jeu vidéo … ben moi je lui dit qu'il va se planter, au risque de faire un pronostic foireux.
Quand on veut apprendre à être maçon, on commence par construire un mur, pas une cathédrale (ça n’empêche pas qu'on finira peut-être par construire cette cathédrale)
C'est en substance ce que je lui dit dans le reste du message : Fait d'abord la version 0.1 avant de faire la 1.0.
C'est un des meilleurs que j'ai trouvé. Une fois ce dernier lu, tu pourras passer au C++ de Bjarne Stroustrup.
Pour compléter le message de Michaël :
int*pointer;// créé un pointeur (4 octet dans ta pile) qui pointe vers une zone mémoire qui contient un entier.int*pointer(12345678);// créé un pointeur vers un entier qui pointe vers l'adresse 12345678 de zone mémoire.int*pointer=12345678;// créé un pointeur vers un entier (initialisé à l'addresse 0) et *ensuite* change la valeur du pointeur pour l'adresse 12345678;MaClass*pointer;// un pointer vers un zone mémoire qui contient un objet de type MaClass. (L'objet en question n'est pas créé)MaClass*pointer(newMaClass(socket));// créé un objet dans le tas de type MaClass et l'initialise avec le constructeur qui prend en entré un pointer vers un QTcpSocket. *Ensuite* il créé un pointeur dans la pile et l'initialise avec l'adresse de l'objet créé (retourné par new)MaClass*pointer(socket);// créé un pointeur qui doit pointer vers un objet de type MaClass et l'initialise avec l'adresse d'une zone mémoire qui contient un QTcpSocket (D'où l'erreur)
NX est un proxy pour le protocole X11. Il transforme les appels X11 en un autre protocole plus adapté au réseau (envoie des ordres seulement, système de cache, …)
Il est surement possible de développer un truc équivalent pour Wayland :
Un proxy sur la machine distante qui parle Wayland à l'appli et qui crache un proto maison.
Un proxy sur la machine locale qui manche du proto maison et qui discute Wayland avec le compositeur.
L'application fonctionne en Wayland sans se rendre compte que l'affichage est déporté.
Bon c'est pas totalement de la transparence réseau puisqu'il faut un proxy installé. Mais l'appli reste la même (locale ou distante) et l'expérience utilisateur aussi (le compositeur wayland discute avec le proxy en Wayland, de manière classique).
Il y ce que j'appelle la règle du "80/20" (qu'on retrouve un peu partout) :
80% du jeu sera fait en 20% du temps. Les derniers 20% du jeu prendront 80% du temps à faire.
Tu auras très facilement (et rapidement) un jeu "complet". Tu auras un système de tiling, du scrolling, de quoi afficher des dialogues, un inventaire, un système de combat et de quêtes.
Tu te diras que c'est bientôt terminer, encore deux trois trucs et c'est bon. En fait, le boulot ne fait que commencer. Il te faudra :
Des petites animations pour que ton monde soit moins mort.
Des quantités de sprites.
La génération procéduriales pour un monde illimité
De nombreuses quêtes
Du son
Plein d'option de configuration
Des objets
Équilibrer les persos, les compétences, les objets et leur coût.
Du bug fix !!!!!!!!
Tout ça prend du temps, énormément de temps. Pris individuellement ça ne change pas fondamentalement le jeu mais c'est ça qui fait que l'on passe d'un jeu amateur à un jeu pro.
Et je choisi mes mots. Ces tâches sont chiantes à réaliser, on a l’impression de ne pas avancer et de ne plus faire évoluer le jeu. C'est pour ces raisons qu'un amateur aura moins tendance à faire ces tâches et que le jeu restera amateur. Un pro lui est payé, c'est toujours chiant mais ça fait parti du boulot. Et c'est à mon avis la première cause des jeux pas fini. Ça n'est pas la difficulté en elle même mais la longueur de la tache et la lassitude qui s'ensuit. Ce n'est pas pour rien qu'on conseil de commencer avec des petits jeux simples, c'est déjà beaucoup plus de boulot qu'on le pense.
Vu que t'as pris les devants sur cette remarque, je suppose que tu es déjà au courant que tu va te planter. Et que je pourrait dire beaucoup de choses, tu ne changera pas d'avis :)
À défaut de te faire changer d'avis :
Ce que tu décris, c'est ta version finale (1.0). Je vais être clair tout de suite: Tout seul, sans expérience dans le dev de jeux vidéo, tu n'atteindra jamais cette version avant de longues années.
Dans 6 mois, quand tu n'auras que du code, qui n'est pas capable d'afficher trois sprites correctement parce que t'auras tout voulu faire en même temps, ben ta motivation et ton courage à faire bouger les montagnes ne seront plus là… (Crois en mon expérience et celles de nombreux autres)
Si tu veux une chance de t'en sortir fait des jalons. Commence avec une version 0.1:
Une carte qui tient dans une fenêtre (donc pas de scrolling), trois sprites différents pour le terrain, une sorcière, une fiole de poison et un chat. Pas de menu, pas de dialogue, pas de notion de RPG (niveau, inventaires, ..)
Et fait tes jalons à l'avance. Il faut qu'à chaque instant tu ais devant toi un but atteignable. Ne part pas dans des dev en te disant "le jour ou j'ai un truc un peu bien ça deviendra la version 0.1".
Fait toi un gros doc qui décrit tes 10 versions (ou plus) avec précision (ce qu'elle doit avoir, ce qu'elle doit pas avoir) et tiens-toi-z'y. Ça doit être ta ligne rouge, ta bouée de survie.
Et quand tu codes, ne pense qu'à la version à venir, pas aux suivantes (t'y a déjà pensé en écrivant le doc).
Et si ça veut dire réécrire tout une partie du code entre deux versions, c'est pas grave.
(Typiquement, pour la version 0.1 n'écrit pas un code d'affichage qui prend en compte le scrolling si c'est prévu pour la version 0.2. Et tant pis si tu dois réécrire cette partie pour rajouter le scrolling après)
Les différents clients (movim, jappix, sat, autre?) utilisent tous l'extensions PubSub d'XMPP pour publier les messages mais ils ont une approche différente.
Est-ce que la différence est seulement sur qui fait le travail (le client pour Jappix, le serveur pour Movim, … pour SAT) ou c'est plus fondamental (la structure des messages, les méta données associées, …) ?
Posé autrement : Est-ce que Alice qui utilise Movim pourra échanger sans problème avec Bob qui utilise Jappix ? Ou est-ce que XMPP/PubSub n'est qu'une couche transport et chacun utilise son format de données (incompatible) à l'intérieur ?
En fait il ne faut pas voir comment ta fonction est définie mais comment elle va être utilisée.
Si tu reviens au c, tu as deux solutions :
inta;function1(a);function2(&a);
Sans connaitre la définition des fonctions, tu sais (le langage te le garantie) que a ne sera pas modifier par function1. Je sais que je peut faire ce que je veux avec a après, je sais que je casserai rien.
Pour function2, tu sais pas. Ça peut être modifié, ou pas. Ça peut être stocké (pour lecture ou modification future) ou pas. Mais tu sais qu'il faut faire attention.
Si tu es en C++ et que ta as des références
inta;function1(a);
Ben là… Mais le c++ ne garantie rien car function1 peut prendre une référence.
L'usage (le mien) voudrait que tu ais la garantie que a soit pas modifié. C'est pour ça que je déconseille très fortement la référence non constante. Le but est de garder la sémantique des passages d'argument du c.
Dans ton premier cas, la fonction sera utilisée de la sorte:
Là, c'est le drame. Tu "demandes" une valeur à l'utilisateur alors que justement tu veux une adresse. Donc : jamais de référence non constante comme argument de fonction. Reste avec un passage d'adresse.
À noter que dans ton cas, il ne faut pas utiliser les références constante non plus (même si tu ne modifie pas castellumBox).
Ton code compile et tu ne modifie pas castellumBox mais tu stockes l’adresse pour l'utiliser plus tard. Tu casses le contrat (purement implicite) de la fonction vers le code appelant : "Fait ce que tu veux avec, moi j'en ai fini, je l'utilise plus".
Si tu fais un delete après l'appel de la fonction:
Le code semble correcte, tu passes une valeur et tu supprime le contenant après utilisation, mais ton programme va se taper un segfault bien méchant (car pas obligatoirement tout de suite et au même endroit)
Rien ne t’empêche de faire l'erreur, mais c'est moins clean : tu passes le contenant et tu le supprimes après. Ça mais la puce à l'oreille.
Après on peut jouer avec les les smart pointer, shared_pointer et unique_ptr pour rajouter une sémantique de "propriété de l'objet" mais ça fait des posts trop long :)
Il reste un cas (le seul?), où le passage par recopie est nécessaire : Quand tu veux explicitement une copie de l'objet (pour la modifier ou la stocker sans interférer avec l'objet d'origine)
Comment sait-on si l'object est "un peu gros" à part faire un benchmark ?
Je vais plutôt répondre à : Quand passer un objet par référence constante plutôt que par valeur (recopie) ?
La réponse rapide : Si l'objet n'est pas modifié: tout le temps. Sinon, passage par adresse (pas par référence).
La réponse longue :
Un passage par référence coute la même chose qu'un passage par adresse : la copie de l’adresse de l'objet (4 octets en 32 bits, 8 en 64 bits). D'un point de vu mémoire, un objet faisant très souvent plus de 4 octets, il doit donc quasiment tout le temps être passé par référence.
De plus la recopie d'un objet (même petit) n'est pas obligatoirement gratuite. Le constructeur par recopie peut faire des opérations relativement longue. Un passage par référence évite la recopie.
Une recopie perd le "type réel" de l'objet et casse le polymorphisme:
Le cassage du polymorphisme peut être voulu, mais ça surprendra probablement l'utilisateur. Et je conseille un appelle explicite à la méthode d'origine si c'est voulu : "toto.Obj::getvalue()"
Par contre, je déconseille très fortement le passage par référence non constante:
À la lecture d'un code déjà écrit, impossible de savoir si l'objet sera modifié par la fonction sans aller voir la définition de celle-ci. Si une fonction modifie un argument, c'est passage par adresse. point. Au moins c'est clair (à la lecture) : je passe l'objet=>pas de modif, je passe l'adresse => modif.
Impossible de passer des objets temporaires. Ce code ne compile pas :
Un joli tableur dans calc sur 24 mois en utilisant ta formule d’amortissement (pas sur qu'elle soit juste en terme comptable) me donne que avec x(0)=1 la somme des x(n) vaut … 5.8
J'ai aucune idée du prix d'un d'achat et d'entretient d'un serveur sur 2 ans mais, étant donnée que la somme est proportionnelle à x(0) :
x(0) = "prix du serveur+marge" / 5.8
avec 3000€ ça donne x0=517€ (x8=92€, x12=10€, x15<1€)
Par contre, il n'y a aucun ordre de rendu géré par SFML. C'est le client (donc ton code) qui fait le rendu dans l'ordre qu'il veut.
Si on suppose que ton jeu contient 10 entités identiques qui s'affiche avec deux quads identiques, chacun utilisant une texture différente.
Tu vas donc avoir au total deux textures(A et B) et un quads qu'il faudra afficher 20 fois (10 avec la texture A, 10 avec la texture B)
Si tu t'y prends mal, tu parcours bêtement les entités et tu fais le rendu : quad_textureA, quad_textureB, quad_textureA, quad_textureB, …
À chaque fois, c'est un changement de texture et tes perfs en prennent un coup (derrière la nuque)
Si tu t'y prends bien, tu peux faire le rendu suivant : quad_textureA, …, quad_textureA, quad_textureB, …, quad_textureB.
À ce moment, t'as que deux changement de texture et c'est la fête. Par contre ça t'oblige à avoir un algo/structure de donnée qui tient la route, tu ne peux plus parcourir dans l'ordre des entités.
(Bien sur ne prend pas mes paroles pour des paroles d’évangile. Il y a beaucoup d'inconnus et ça m'étonnerai pas que les coûts de changement varient suivant les cartes graphiques et les drivers. On en revient à la base : Fais un truc qui marche, fais des tests, optimise. (mais pense quand même au problème de loin quand tu fais ton archi)
Et puis le deuxième problème, c'est qu'il faut l'entité associée au composant et si tu parcoures les composants tels quels, tu auras du mal à savoir quelle est l'entité correspondante.
Justement, sur un système "monocomposant", tu n'as pas à connaitre l'entité associée.
Après y avoir réfléchi tout l’après midi, je pense que tu as raison. J'ai accroché sur ta phrase où tu parles d’optimisation par rapport au cache mais en fait c'est loin d'être important. Tu auras plein d'autre problème de perf avant de devoir régler celui la.
En vrac on peut citer :
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 ?).
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 ?
Si tu dois optimiser ta lib, pose toi ces questions là avant de voir les problèmes de cache. (En gros continue ce que tu fais :) )
[1] De manière surprenante, les articles et moteur 3D "basique" ne prennent absolument pas ce fait en compte. Ils ordonnent le rendu des objets pour faire les plus proches en premier et ainsi éviter de dessiner complètement les objets qui seront cachés ensuite par d'autres. Mes tests m'ont montrer que ce n'était pas vraiment là qu'il fallait optimiser. (Ça fait quelque temps que j'ai pas regardé les articles sur le sujet, ça a peut être changer entre temps.)
Dans un de mes anciens projets pro (qui a était annulé faute de budget. :( ). 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.
[^] # Re: Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à 2.
C'est sur ce genre de phrase que tu casses tout le débat. Tes idées ne sont pas stupides, elle ne sont simplement pas obligatoirement en accord avec tout le monde et elles méritent d'êtres discutées.
Mes ce genre d'attaques Ad hominem et autres positions extrémistes décrédibilisent beaucoup de ton propo.
Matthieu Gautier|irc:starmad
[^] # Re: Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à 3. Dernière modification le 07 octobre 2013 à 15:40.
Tu apprendra que je n'ai ni femme ni enfants. Je suis célibataire et ma famille habite à 900km de moi.
Je ne travaille pas le dimanche. Par contre j'ai des amis qui sont en milieux hospitalier qui font des gardes le dimanche ou les nuits. Des gens de ma famille sont régulièrement d'astreinte le dimanche (c'est super cool quand je vais les voir le we et qu'on ne peut pas quitter la ville).
La société que je décrit (qui n'est pas obligatoirement mon choix) est celle qui existe depuis longtemps (et oui, ça peut être amener à changer). Les gens qui travail le dimanche font partie des exceptions. Et ça ne doit pas ce généraliser. Si c'était le cas ça ne serait pas la même société. Et c'est pourquoi il y a un débat. Vous prenez les gens pour des imbéciles quand vous niez ce changement de société et réduisez le débat au choix individuel.
Matthieu Gautier|irc:starmad
[^] # Re: Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à 0.
Tout à fais, et tu as raison. La société peut évoluer (et doit évoluer). Travail dominical ou mariage homosexuel sont des choix de sociétés pas des choix individuels.
C'est ce point que je critique, pas le travail dominical ou le mariage homo en eux-même.
Matthieu Gautier|irc:starmad
[^] # Re: Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à 2.
Je ne dit pas qu'il n'est pas possible de tirer un trait dessus. Je dit que c'est un choix de société et que quelque soit le choix, ce choix est imposé à l'ensemble de la société.
Vous pouvez parler de liberté individuel, c'est un argument qui ce tient. Mais vous ne pouvez pas dire que vous n'imposez rien aux autres.
Matthieu Gautier|irc:starmad
[^] # Re: Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à 1.
Non, avec ton modèle les gens peuvent trouvé du temps commun avec leur proche et faire des trucs avec eux.
Ce n'est pas un temps commun pour la Société (avec un grand S)
Je ne défend pas ma petite vie familiale (j'en ai pas). Je ne défend pas le modèle de société actuel. Je mets juste en avant que le problème ce n'est pas la liberté individuel, le salaire double ou la création d'emploi.
Pendant 2000 ans, la société (pas les gens) a eu un jour "commun". C'était pour des raisons différentes de maintenant mais ça était. Généraliser le travail le dimanche, c'est tirer un trait sur un point important de notre modèle de société.
Matthieu Gautier|irc:starmad
[^] # Re: Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à -1.
Autant je suis pour le mariage homosexuel. Autant j'ai grandement regretter que les opposants au mariage homosexuel soit systématiquement ramener à des cato de droite réact et homophobe.
C'est très bien pour casser le débat dans l'oeuf mais ça ne fait pas un débat de société. Et ça réduit grandement la "victoire" du mariage homosexuel imposé de force et sans réelle débat sur les changements de société que ça inclue.
Matthieu Gautier|irc:starmad
[^] # Re: Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à 4.
Tu sera gentils de ne pas me préter des idées que je n'ai pas et pour lesquelles tu n'as aucune idée de mon point de vu. Ça améliorera le débat.
Pour info, je m'interdit d'aller au magasin le dimanche. Je vais au ciné en semaine. Le dimanche je le passe chez moi ou avec des amis (transport en voiture)
Je n'ai jamais dit si j'était pour ou contre le travail le dimanche, j'ai juste essayé de recentrer le débat sur ce qui me semble important : le temps commun. Sujet que tu t'es empressé d'éviter au nom de la binarisation des idées.
Matthieu Gautier|irc:starmad
[^] # Re: Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à 4.
J'en ai rien à foutre des autres sociétés. Je te parle de la société dans laquelle je vie et dans laquelle le débat a lieu.
Si tu aurais lu mon commentaire en entier tu aurais pu lire ceci :
Matthieu Gautier|irc:starmad
# Choix de société.
Posté par GaMa (site web personnel) . En réponse au journal Travail dominical. Évalué à 7.
Le problème du travail le dimanche est avant tout un problème de société. C'est un choix de société et pas un choix individuel.
Le problème n'est pas vraiment de savoir si le travailleur du dimanche est volontaire ou forcé et si il sera payé le double ou pas. (Enfin, ce sont des problèmes mais pas les plus primordiaux)
Lorsqu'on vie en société c'est avant tout vivre ensemble avec des règles communes et "fonctionnements" communs. Avoir les mêmes rythmes de vie.
Le dimanche chômé n'a plus grand chose à voir avec la religion. Le but est d'avoir un jour commun où la société se dit : "stop, nous avons un jour où l'ensemble des gens peuvent se voir". Le fait que ce jour soit le dimanche est certes un conséquence du christianisme qui avait instauré ce jour comme jour de communion mais il ça n'a plus rien a voir maintenant, l'important est que ce soit un jour commun.
Autorisé le travail le dimanche (vraiment, pas juste donner des exceptions) c'est cassé cette règle commune. C'est donc une atteinte à la vie commune, à notre société. C'est quelque chose d’extrêmement important qui mérite vraiment un débat (et pour les bonnes choses, pas pour des questions de salaires). C'est une évolution de la société qui doit être décidée ensemble et qui ne peut pas (juste) se justifier par des libertés individuelles.
Quand vous parlez de libertés individuelles pour justifier le travail le dimanche avec la liberté de choisir son jour de repos, à mes yeux, vous avez un discours asocial[1].
Le jour où il n'y a plus de jour commun de repos, il n'y a plus de vie commune. Certes les gens continuerons de voir leur amis. Mais quand organiser les activités communes qui s'étendent sur une journée si chacun a sa journée ?
Le but du
dimanchejour de repos commun c'est la consolidation de la société autour d'un temps commun. C'est la même chose avec les horaires de travail journaliers : le soir, on ne travail pas (en général), on peut organiser un vie commune.Oui, il y a des exceptions, oui il doit y en avoir mais ça doit rester des exceptions. Ces exceptions ne doivent être que les besoins premiers (santé, énergie) et pour des activités liés à cette vie commune : voir des amis (cinéma, resto, bar), faire la fête (boite de nuit), faire du sport (club de sport), partir en we, voir la famille (transport), …
Le fait que les gens puissent aussi le faire à d'autre moment n'est pas un argument valide pour le supprimer. Le but n'est pas que les gens aient du temps, c'est qu'ils aient un temps commun.
Pouvoir acheter sa plomberie le dimanche, oui, c'est sympa. Pouvoir être payer double parce que l'on travail le dimanche, oui, c'est sympa. Mais c'est un acte individuel. Est-ce que ça vaut ce changement qui touche à un fondement de notre société ? (C'est une vrai question, si ce n'est pas la question du débat)
[1] Dans le sens opposé à la société, je n'est aucun doute sur le fait que vous êtes sociaux, que vous voyez des gens, ..
Matthieu Gautier|irc:starmad
[^] # Re: Réinventer la roue, NIH ?
Posté par GaMa (site web personnel) . En réponse à la dépêche systemd 208 : logind et Wayland. Évalué à 4. Dernière modification le 04 octobre 2013 à 17:30.
Tu peux aussi filtrer sur le label de la partition, le constructeur/modèle de la clé, …
Après, si tu veux connaitre l'appartenance de n'importe quel périphérique inconnu, sans caractéristique particulière et branché sur n'importe quel port … il reste la caméra pour détecter qui branche le périphérique. (je te laisse le coder, ça devrait être facile :) )
Matthieu Gautier|irc:starmad
[^] # Re: Réinventer la roue, NIH ?
Posté par GaMa (site web personnel) . En réponse à la dépêche systemd 208 : logind et Wayland. Évalué à 1.
udev (et donc systemd) permet d'avoir des règles spécifiques selon le périphérique (UUID). Je ne sais pas si la fonctionnalité est implémentée mais il ne devrait pas être trop difficile d'avoir un règle du type :
clé usb UUID "machin" => utilisateur toto.
D'ailleurs c'est peut-être ce qui est fait par goulou mais avec une règle sur le port USB plutôt que sur le périphérique.
Matthieu Gautier|irc:starmad
[^] # Re: NX pour Wayland.
Posté par GaMa (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.
Effectivement. Gtk doit aussi en avoir un. (Qt5 ne l'a plus).
Par contre c'est pas sur qu'ils l'utilisent et d'après les dev de Wayland (et donc Xorg) il semble que ça ne soit pas le cas. Et vu l’engouement des dev de toolkit à passer à Wayland, je pense qu'ils sont tous d'accord.
Non :)
NX par du principe que X11 n'est pas adapté au réseau. Il transmet les ordres X mais maintient un cache (dupliqué dans les deux proxys) de toutes les données.
Dire qu'un NWayland serait mois efficace est un peu rapide à mon goût : un diff d'image, de la compression et un système de cache ça réduit drastiquement le débit de donnée pour des applis classiques. Ça pourrait même être moindre que NX vu qu'il y a moins d'ordres à transmettre.
Les applis X qui passent par NX ne connaissent pas le protocole NX. Pourquoi les applis Wayland qui passent par NWayland devraient connaitre le protocole NWayland. C'est tout l'avantage d'avoir proxy qui fait la traduction.
Matthieu Gautier|irc:starmad
[^] # Re: NX pour Wayland.
Posté par GaMa (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 5.
Justement, il y a quasiment plus de toolkit qui utilise X "à l'ancienne" (à ma connaissance, dans les toolkits actuels (à défaut de modernes) il ne reste que Tk)
Et puis NX n'utilise pas le proto X11, justement parce que X11 n'est pas adapté. (je vous conseil de lire cet article : http://www.linuxjournal.com/article/8477?page=0,0 (au moins le début))
C'est pour ça que Wayland ne supporte pas le "network-capable". Il y a d'autres protocoles bien plus efficaces que X pour transférer des buffers et de moins en moins de projets utilisent X de manière "native".
Autant faire un proto local et utiliser les autres proto pour le distant. Si c'est bien intégré (ce dont je ne doute pas si on laisse le temps) ça équivaudra à un "ssh -W"
Matthieu Gautier|irc:starmad
[^] # Re: Trop gros, passera pas.
Posté par GaMa (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E02 : le jeu et ses challenges. Évalué à 3.
Ne l'écoute pas rewind quelqu'un à peine capable de trouver le sujet de ses phrases ne peut t'apporter aucune aide digne de ce nom :)
Plus sérieusement, j'espère vraiment me tromper et que tu vas réussir. (Mais vraiment ! Je souhaite sincèrement avoir tort)
Mais voilà, quand je vois arriver quelqu'un qui annonce qu'il va faire un nouveau RPG avec une carte très très grande, de la génération procédurale, un monde ouvert, plein de quêtes et les derniers effets visuels à la mode et qu'en plus, il a pas d'expérience dans le jeu vidéo … ben moi je lui dit qu'il va se planter, au risque de faire un pronostic foireux.
Quand on veut apprendre à être maçon, on commence par construire un mur, pas une cathédrale (ça n’empêche pas qu'on finira peut-être par construire cette cathédrale)
C'est en substance ce que je lui dit dans le reste du message : Fait d'abord la version 0.1 avant de faire la 1.0.
Matthieu Gautier|irc:starmad
[^] # Re: Masquage d'identifiant
Posté par GaMa (site web personnel) . En réponse au message Constructeur : mauvais constructeur choisi. Évalué à 3.
Pour un bouquin je te conseille "Apprendre le C++" de Claude Delannoy au édition Eyrolles : http://www.editions-eyrolles.com/Livre/9782212121353/
C'est un des meilleurs que j'ai trouvé. Une fois ce dernier lu, tu pourras passer au C++ de Bjarne Stroustrup.
Pour compléter le message de Michaël :
Matthieu Gautier|irc:starmad
# NX pour Wayland.
Posté par GaMa (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 7.
NX est un proxy pour le protocole X11. Il transforme les appels X11 en un autre protocole plus adapté au réseau (envoie des ordres seulement, système de cache, …)
Il est surement possible de développer un truc équivalent pour Wayland :
Bon c'est pas totalement de la transparence réseau puisqu'il faut un proxy installé. Mais l'appli reste la même (locale ou distante) et l'expérience utilisateur aussi (le compositeur wayland discute avec le proxy en Wayland, de manière classique).
Matthieu Gautier|irc:starmad
[^] # Re: Trop gros, passera pas.
Posté par GaMa (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E02 : le jeu et ses challenges. Évalué à 5.
Il y ce que j'appelle la règle du "80/20" (qu'on retrouve un peu partout) :
80% du jeu sera fait en 20% du temps. Les derniers 20% du jeu prendront 80% du temps à faire.
Tu auras très facilement (et rapidement) un jeu "complet". Tu auras un système de tiling, du scrolling, de quoi afficher des dialogues, un inventaire, un système de combat et de quêtes.
Tu te diras que c'est bientôt terminer, encore deux trois trucs et c'est bon. En fait, le boulot ne fait que commencer. Il te faudra :
Tout ça prend du temps, énormément de temps. Pris individuellement ça ne change pas fondamentalement le jeu mais c'est ça qui fait que l'on passe d'un jeu amateur à un jeu pro.
Et je choisi mes mots. Ces tâches sont chiantes à réaliser, on a l’impression de ne pas avancer et de ne plus faire évoluer le jeu. C'est pour ces raisons qu'un amateur aura moins tendance à faire ces tâches et que le jeu restera amateur. Un pro lui est payé, c'est toujours chiant mais ça fait parti du boulot. Et c'est à mon avis la première cause des jeux pas fini. Ça n'est pas la difficulté en elle même mais la longueur de la tache et la lassitude qui s'ensuit. Ce n'est pas pour rien qu'on conseil de commencer avec des petits jeux simples, c'est déjà beaucoup plus de boulot qu'on le pense.
Matthieu Gautier|irc:starmad
# Trop gros, passera pas.
Posté par GaMa (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E02 : le jeu et ses challenges. Évalué à 10.
Je vais être franc : Tu vises trop gros !
Vu que t'as pris les devants sur cette remarque, je suppose que tu es déjà au courant que tu va te planter. Et que je pourrait dire beaucoup de choses, tu ne changera pas d'avis :)
À défaut de te faire changer d'avis :
Ce que tu décris, c'est ta version finale (1.0). Je vais être clair tout de suite: Tout seul, sans expérience dans le dev de jeux vidéo, tu n'atteindra jamais cette version avant de longues années.
Dans 6 mois, quand tu n'auras que du code, qui n'est pas capable d'afficher trois sprites correctement parce que t'auras tout voulu faire en même temps, ben ta motivation et ton courage à faire bouger les montagnes ne seront plus là… (Crois en mon expérience et celles de nombreux autres)
Si tu veux une chance de t'en sortir fait des jalons. Commence avec une version 0.1:
Une carte qui tient dans une fenêtre (donc pas de scrolling), trois sprites différents pour le terrain, une sorcière, une fiole de poison et un chat. Pas de menu, pas de dialogue, pas de notion de RPG (niveau, inventaires, ..)
Et fait tes jalons à l'avance. Il faut qu'à chaque instant tu ais devant toi un but atteignable. Ne part pas dans des dev en te disant "le jour ou j'ai un truc un peu bien ça deviendra la version 0.1".
Fait toi un gros doc qui décrit tes 10 versions (ou plus) avec précision (ce qu'elle doit avoir, ce qu'elle doit pas avoir) et tiens-toi-z'y. Ça doit être ta ligne rouge, ta bouée de survie.
Et quand tu codes, ne pense qu'à la version à venir, pas aux suivantes (t'y a déjà pensé en écrivant le doc).
Et si ça veut dire réécrire tout une partie du code entre deux versions, c'est pas grave.
(Typiquement, pour la version 0.1 n'écrit pas un code d'affichage qui prend en compte le scrolling si c'est prévu pour la version 0.2. Et tant pis si tu dois réécrire cette partie pour rajouter le scrolling après)
Matthieu Gautier|irc:starmad
# Compatibilité entre les clients
Posté par GaMa (site web personnel) . En réponse à la dépêche Monter votre propre réseau social avec Movim et Metronome. Évalué à 3.
Les différents clients (movim, jappix, sat, autre?) utilisent tous l'extensions PubSub d'XMPP pour publier les messages mais ils ont une approche différente.
Est-ce que la différence est seulement sur qui fait le travail (le client pour Jappix, le serveur pour Movim, … pour SAT) ou c'est plus fondamental (la structure des messages, les méta données associées, …) ?
Posé autrement : Est-ce que Alice qui utilise Movim pourra échanger sans problème avec Bob qui utilise Jappix ? Ou est-ce que XMPP/PubSub n'est qu'une couche transport et chacun utilise son format de données (incompatible) à l'intérieur ?
Matthieu Gautier|irc:starmad
[^] # Re: Très rapide review
Posté par GaMa (site web personnel) . En réponse au journal Petit Framework de jeu 2d en C++. Évalué à 3.
En fait il ne faut pas voir comment ta fonction est définie mais comment elle va être utilisée.
Si tu reviens au c, tu as deux solutions :
Sans connaitre la définition des fonctions, tu sais (le langage te le garantie) que a ne sera pas modifier par function1. Je sais que je peut faire ce que je veux avec a après, je sais que je casserai rien.
Pour function2, tu sais pas. Ça peut être modifié, ou pas. Ça peut être stocké (pour lecture ou modification future) ou pas. Mais tu sais qu'il faut faire attention.
Si tu es en C++ et que ta as des références
Ben là… Mais le c++ ne garantie rien car function1 peut prendre une référence.
L'usage (le mien) voudrait que tu ais la garantie que a soit pas modifié. C'est pour ça que je déconseille très fortement la référence non constante. Le but est de garder la sémantique des passages d'argument du c.
Dans ton premier cas, la fonction sera utilisée de la sorte:
C'est clair, tu attends une adresse parce que tu veux faire un truc avec. L'utilisateur doit faire attention à ce qu'il fait.
Dans ton deuxième cas :
Là, c'est le drame. Tu "demandes" une valeur à l'utilisateur alors que justement tu veux une adresse. Donc : jamais de référence non constante comme argument de fonction. Reste avec un passage d'adresse.
À noter que dans ton cas, il ne faut pas utiliser les références constante non plus (même si tu ne modifie pas castellumBox).
Ton code compile et tu ne modifie pas castellumBox mais tu stockes l’adresse pour l'utiliser plus tard. Tu casses le contrat (purement implicite) de la fonction vers le code appelant : "Fait ce que tu veux avec, moi j'en ai fini, je l'utilise plus".
Si tu fais un delete après l'appel de la fonction:
Le code semble correcte, tu passes une valeur et tu supprime le contenant après utilisation, mais ton programme va se taper un segfault bien méchant (car pas obligatoirement tout de suite et au même endroit)
Avec un passage par adresse :
Rien ne t’empêche de faire l'erreur, mais c'est moins clean : tu passes le contenant et tu le supprimes après. Ça mais la puce à l'oreille.
Après on peut jouer avec les les smart pointer, shared_pointer et unique_ptr pour rajouter une sémantique de "propriété de l'objet" mais ça fait des posts trop long :)
Il reste un cas (le seul?), où le passage par recopie est nécessaire : Quand tu veux explicitement une copie de l'objet (pour la modifier ou la stocker sans interférer avec l'objet d'origine)
Matthieu Gautier|irc:starmad
[^] # Re: Très rapide review
Posté par GaMa (site web personnel) . En réponse au journal Petit Framework de jeu 2d en C++. Évalué à 5.
Je vais plutôt répondre à : Quand passer un objet par référence constante plutôt que par valeur (recopie) ?
La réponse rapide : Si l'objet n'est pas modifié: tout le temps. Sinon, passage par adresse (pas par référence).
La réponse longue :
Un passage par référence coute la même chose qu'un passage par adresse : la copie de l’adresse de l'objet (4 octets en 32 bits, 8 en 64 bits). D'un point de vu mémoire, un objet faisant très souvent plus de 4 octets, il doit donc quasiment tout le temps être passé par référence.
De plus la recopie d'un objet (même petit) n'est pas obligatoirement gratuite. Le constructeur par recopie peut faire des opérations relativement longue. Un passage par référence évite la recopie.
Une recopie perd le "type réel" de l'objet et casse le polymorphisme:
Le cassage du polymorphisme peut être voulu, mais ça surprendra probablement l'utilisateur. Et je conseille un appelle explicite à la méthode d'origine si c'est voulu : "toto.Obj::getvalue()"
Par contre, je déconseille très fortement le passage par référence non constante:
Avec "void test(const Obj& toto)" ça compile.
Matthieu Gautier|irc:starmad
[^] # Re: mignon
Posté par GaMa (site web personnel) . En réponse au journal Initiative citoyenne pour le revenu de base. Évalué à 4.
Sauf qu'il n'y aura plus de chômage, tout est dans le revenu de base.
Matthieu Gautier|irc:starmad
[^] # Re: Le bon prix
Posté par GaMa (site web personnel) . En réponse au journal OVH, rupture de stock sur les serveurs dédiés. Évalué à 3. Dernière modification le 19 septembre 2013 à 18:26.
Un joli tableur dans calc sur 24 mois en utilisant ta formule d’amortissement (pas sur qu'elle soit juste en terme comptable) me donne que avec x(0)=1 la somme des x(n) vaut … 5.8
J'ai aucune idée du prix d'un d'achat et d'entretient d'un serveur sur 2 ans mais, étant donnée que la somme est proportionnelle à x(0) :
x(0) = "prix du serveur+marge" / 5.8
avec 3000€ ça donne x0=517€ (x8=92€, x12=10€, x15<1€)
Sur 48 mois, ça donne x0=361€, x17=10€ et x22<1€
Matthieu Gautier|irc:starmad
[^] # Re: Duck typing et implementation
Posté par GaMa (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 3.
Et bien je viens de regarder le code de SFML, tu fais bien de prendre des pincettes ;)
SFML est bien codé, pas de soucis la dessus mais il ne fait pas les optims sus-citées.
Les seules optimisations faites à ce niveau sont de ne pas changer une texture (ou blend mode) si elle est déjà celle courante (https://github.com/LaurentGomila/SFML/blob/master/src/SFML/Graphics/RenderTarget.cpp#L192-L198)
Par contre, il n'y a aucun ordre de rendu géré par SFML. C'est le client (donc ton code) qui fait le rendu dans l'ordre qu'il veut.
Si on suppose que ton jeu contient 10 entités identiques qui s'affiche avec deux quads identiques, chacun utilisant une texture différente.
Tu vas donc avoir au total deux textures(A et B) et un quads qu'il faudra afficher 20 fois (10 avec la texture A, 10 avec la texture B)
(Bien sur ne prend pas mes paroles pour des paroles d’évangile. Il y a beaucoup d'inconnus et ça m'étonnerai pas que les coûts de changement varient suivant les cartes graphiques et les drivers. On en revient à la base : Fais un truc qui marche, fais des tests, optimise. (mais pense quand même au problème de loin quand tu fais ton archi)
Matthieu Gautier|irc:starmad
[^] # Re: Duck typing et implementation
Posté par GaMa (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 3.
Justement, sur un système "monocomposant", tu n'as pas à connaitre l'entité associée.
Après y avoir réfléchi tout l’après midi, je pense que tu as raison. J'ai accroché sur ta phrase où tu parles d’optimisation par rapport au cache mais en fait c'est loin d'être important. Tu auras plein d'autre problème de perf avant de devoir régler celui la.
En vrac on peut citer :
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 ?).
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 ?
Si tu dois optimiser ta lib, pose toi ces questions là avant de voir les problèmes de cache. (En gros continue ce que tu fais :) )
[1] De manière surprenante, les articles et moteur 3D "basique" ne prennent absolument pas ce fait en compte. Ils ordonnent le rendu des objets pour faire les plus proches en premier et ainsi éviter de dessiner complètement les objets qui seront cachés ensuite par d'autres. Mes tests m'ont montrer que ce n'était pas vraiment là qu'il fallait optimiser. (Ça fait quelque temps que j'ai pas regardé les articles sur le sujet, ça a peut être changer entre temps.)
Dans un de mes anciens projets pro (qui a était annulé faute de budget. :( ). Une des optims qui était prévu était de faire le rendu en deux passes :
Matthieu Gautier|irc:starmad