moi1392 a écrit 740 commentaires

il y a des paquets garmin-ant-downloader et garmin-forerunner-tools au moins sous debian.
Remarque, la dernière fois que j'ai tenté de récuperer mes données, ça n'avais pas marché.
L'outil (qui utilise libusb en interne) n'arrivait pas à reconnaitre le dongle alors qu'il était reconnu avec lsusb.
Après une petite séance de débogage, j'ai compris que le bogue était dans l'utilisation de libusb et que la méthode de lsusb fonctionnait mieux, j'aivais entrepris de porter le bouzin, mais sans succes… (faut dire aussi que si j'y avait passé plus d'une heure, j'aurais eu plus de chances…)
Si tu as des nouvelles de ce front, ça m'intéressse (je referai peut-être une tentative un de ces 4)

Ça à l'air chouette ! du coup je m'y suis inscrit !
S'il y a des linuxéfairiens qui seront sur place on pourrait profiter de l'occasion de se croiser et découvrir un peu qui on moinsse à longueur de journée :)

Je pense surtout qu'on y arrive naturellement en codant le chose et en apprenant de ses erreur et projets passés.
Quand j'ai lu ton message sur le entity system, beaucoup de choses mon paru naturelles alors que je ne m'étais jamais renseigné sur le sujet.
Le truc qui est cool par contre, c'est d'arriver à la formaliser, à comprendre ce qu'il y a d'intéressant, à voir aussi les défauts, pour ne pas l'utiliser à toutes les sauces (un peu comme quand tu découvres l'héritage ou les templates… j'en ai mis partout et nimporte comment moi :D)

tu sais que si tu arrives à me faire me lancer dans un projet, je te maudirai jusqu'à la 1392ème génération ?

si tu veux on se fait une séance de code revue un de ces 4 et je te dit ce que j'en pense.
Sans trop rentrer dedans ni trop connaitre, ça sera plutôt des considérations esthétiques, mais c'est toujours ça de pris !

En fait, c'est plus le projet en lui même qui m'embete.
Comme je l'ai déjà écrit dans un message sur une de tes dépêches, j'ai écrit un petit moteur de RPG quand j'étais étudiant qui faisait des trucs sympa. Les graphismes étant honteusement pompés de jeux proprios et libres (secret of mana, the mana world et rpg maker 95)
Mais je me suis fait avoir car il me manquait la partie screenbord et plan de ce que je voulais vraiment. Et je sais que là, je n'ai pas plus avancé là dessus.

Ce qui me motiverai plus, ça serait un projet plus petit, genre un moteur de defense tower assez customizable pour que les gens puissent faire leur propre lvl et modifiant la difficulté, voir certaines règles de base.
Là je serait partant ! Mais l'autre soucis est que je suis très stricte et exigeant sur la qualité du code, du coup ça serait trop chiant de bosser avec moi et je me ferais jeter de la team illico :D

tu utilises debian !!
Je savais que tu étais quelqu'un de bien, malgrès tes déviances java :D

ha, tu parles de ton nouveau project, moi je pensais à newton adventure !

C'est ce que j'ai cru comprendre et je me suis à un moment posé la question :)
Et je me suis trouvé une autre excellente excuse pour eviter d'entrer dans un projet qui me prendra beaucoup de temps.
Reste plus qu'à me souvenir laquelle !

(hum.. je suis crédible là ?)

nickel alors :)

Juste une question que je me suis posé en lisant la dépêche sur les entity système.
Pourquoi ne pas juste les ranger les composants dans des listes et les faire réferencer par les entités ?
Comme ça, pour processer un type de composant, tu attaques directement la liste sans te soucier de quelle entité est connectée dessus (ça rejoins un peu l'idée du scene graph en fait), et tu n'as pas besoin de faire une lourde requete sur des associations entre entités et composants !

Pour le coup de battre un bon driver, détrompe toi ! quand on sait ce que l'on fait, on est toujours meilleur que les optimisations générales d'un sous sytème.
L'exemple simple est de ne pas faire une opération quand elle est déjà faite ou inutile car tu n'en auras plus besoin (genre appeler sort sur un tableau que tu sais déjà trié). Ça, aucun sous système ne peut le décider à ta place, et tu gagnes un facteur temps infini ;)

Oui, mais il y a 2 contres indications que je connais aux "moteurs 3d"

1) si tu fais un tout petit truc, il faut quand mêem éviter d'utiliser une usine autour pour gêrer le rendu.

1,5) si tu aimes bien coder et que tu as envie de t'amuser à le faire toi même parce que ça te botte et que tu as envie d'apprendre et de progresser dans le domaine.

2) si tu as des besoins très spécifiques qui ne sont pas gêrés par un moteur 3d classique (genre beaucoup de rotations)

Je pense que dans son cas, il est partit de 1) et maintenant il est à 2), tout en ayant passé par l'étape 1,5)

Dans ce ce cas là, vbo + shaders + scenegraph.
Et surtout, minimiser les changement d'états d'OpenGL !

Sans rentrer dans l'optimisation par carte (je n'ai jamais eu besoin d'aller jusque là moi, au boulot on a une liste de cartes + drivers officiellement supportés pour les clients, en gros, la plus grosse nvidia à 999999$, pour le reste, ils changent de carte ou ils peuvent courrir… :D), ça fait déjà pas mal la différence.

Si j'avais un peu plus de temps (et que c'était codé en c++. Désolé, mais il faut aussi que ça m'amuse un peu ;)) je m'en serais vonlontier mêlé un peu ;)

j'ai pas tout lu.
Mais dans ton nouveau code tu mélanges des shader aussi et ça alourdi pas mal.
Les shader gèrent le traitement de des données (ici, le pipe graphique) et sont indépendant de la soumissions des données (immediate mode, display list, vbo, …)

Après, je me permet une remarque (et je me trompe peut-être car je n'ai pas tout le code sous la main), mais dans ton code d'origine, j'ai l'impression que tu parcours ton data model pour faire l'affichage.
C'est là que ta séparation code/donnée est mal faite !

Dans ton parcours de data model, tu dois construire un noeud de scenegraph avec seulement les infos utiles pour le rendu :
une seule matrice de transformation (tu la calcules à ce moment précis)
Ton mesh (les vertex avec tous leurs attributs)
Les données supplémentaires (reference vers une texture à bind, shader particulier à utiliser…)
Les states OpenGL dont tu as besoin (material, lights, …)

Ton rendu se fait ensuite en parcourant ton scenegraph, appliquand le state, la matrice de transformation et soumettant les données.
Ça c'est pour un scene graph simple (sans effet compliqué de lumière, transparence, …) et sans essayer de minimiser les changement d'états d'OpenGL qui coutent très cher.

Tu peux alors mettre à jour juste une partie de ces données (une entité de ton jeu met à jour son noeud dans le scene graph)
Tu peux également faire le rendu dans un thread distinct pour garder un framerate constant et utiliser un lock sur les noeuds que tu mets à jour (ou construire un noeud à coté et juste faire un remplacement quand il est fini)
Et tu retrouve un "logique" qui ressemble à du direct mode dans ton code "de dessin" qui est en fait le code de création d'un noeud de scene graph tout en ayant un rendu optimisé et surtout découplé du reste du code, donc facile à faire évoluer.

Après, c'est peut-être ce que tu fais déjà avec ta classe Sprite et je l'ai mal compris juste.

Disons qu'organiser toutes les données d'une application dans de gros buffers globaux, ce n'est pas naturel en développement objet :-)

Tu veux dire en java :D ? (ok ok, c'était un blague…)
Mais pas tant que ça en fait, d'un point de vue optimisation mémoire (surtout gestion cache et fragmentation), avoir des données "volumineuses" dans de gros buffer et que les objets aient juste les entrées pour y acceder n'est pas si mauvais que ça.
Et d'un point de vue programmation objet, je ne vois pas de soucis non plus. La POO pour moi (c'est un avis personnel et discutable) me donne surtout des outils pour gêrer les relations entre les données et leur traitement ainsi le flux d'execution (à un niveau assez élevé, je ne parle pas des for, if, …)
Mais je prends toujours (ok, pas toujours du tout… mais je sais que c'est mal !) soin de séparer correctement mes données de mon code de traitement.
Au final, cela est assez agnostique de "l'endroit" ou tu ranges tes données, il suffit de bien encapsuler tes accès et tout se passe bien.

Après, on parle d'optimisation ! C'est sur que si tu n'en as pas besoin, et bien ça peut paraitre lourd à faire de cette manière.

Mais je pense aussi que si tu n'en as pas besoin, c'est que tu n'as pas besoin d'un accès direct au métériel non plus, donc peut-être qu'utiliser une surcouche comme SDL (si tu reste en 2D) serait plus intéressant pour toi.
Il faut bien se rendre compte que la lib OpenGL est écrite pour les gros besoins en performance, donc ça ne me surprends pas que cela colle avec une organisation optimale de données en mémoire.

Je trouve que les premières versions d'opengl avaient réussit à abstraire la réalité du hardware

OpenGL a toujours été près du matériel, la différence c'est qu'à l'époque, les cartes fonctionnaient de façon très différente.

Je pense que ce mouvement qui vise à donner aux développeurs un accès direct au hardware est bon pour les performances, mais mauvais pour la concurrence et l'innovation: un nouveau constructeur de carte graphique ne peut que faire comme les autres.

Là dessus je suis d'accord. Je ne pense pas que cela favorise l'innovation car il faudrait que quelqu'un avec une approche différente arrive avec un truc bien mieux que ce qu'il se fait actuellement pour arriver à percer (un peu comme à l'époque du glide).
Mais si on arrive par le bas (ce qui est un peu plus réaliste), on n'a pas le choix et il faut se contenter de suivre.

Mais c'est bien ce que je dis. Moi aussi ça me fait bondir. Pourquoi me répondre en faisant usage de moultes point d'exclamations alors ?

Parce que tu as dit "ça n'est sûrement pas un ramasse miettes complet" et que tu as enchainé avec la comparaison voiture indispensable à toute explication informatique.
Moi ce que je dis, c'est que ça n'est pas un ramasse miette tout court ! de près comme de loin !! Sinon tu peux aussi considerer new et delete comme des ramasses miettes.

Pardonne mon agressivité, mais on s'en fiche de ton cas personnel.

C'est pour cela qu'il y avait une seconde phrase après.. faut lire jusqu'au bout aussi…

La question est de savoir si pour la grande majorité des développeurs, C++ est plus difficile à utiliser/maitriser. Franchement, c'est quelquechose de généralement admis (demande à des profs d'informatique et aux étudiants) et prétendre le contraire, c'est un peu du troll.

Les profs d'informatique et étudiant ne sont pas des développeurs pour moi. Pour chaque prof que j'ai eu, le langage qu'ils enseignait était le meilleur de tous, avec arguments.
Tu comprends bien que même sans connaitre les arguments en question, il y a une impossiblité quelque part…
Ensuite, pour le "C++ est plus difficile à utiliser/maitriser", je suis d'accord qu'il est un peu plus dur à maitriser que d'autres langagues. Mais là, on parlait d'utilisation, pas d'apprentissage ! Donc non, je ne suis pas d'accord.

Pour la fin, tu sors les même arguments que mes profs "qui s'y connaissent" :
en c++, c'est la merde, tu peux faire n'importe quoi. Mais dans mon super langage, tout va bien !! Bien sur, il faut éviter de faire n'importe quoi.. mais quand tu as compris et maitrisé les concepts 1, 2, 8 et 43, franchement, c'est nickel !
Et bien c'est pareil en c++ ! Y'a peut être un peu plus de concepts, ils sont peut-être un peu moins usuel quand on est habitué à d'autres choses, mais compte les personnes qui font n'importe quoi en C++ et celles qui font n'importe quoi en java, je pense que la proportion ne dois pas être si différente que ça.

glBegin et glEnd sont excellent …pour l'apprentissage.
En général, si tu dois torturer ton code pour qu'il s'en passe, c'est que déjà à l'origine, soit :
- tu as une mauvaise séparation de tes données et algorithmes.
- tu as organisé ton code en pensant glBegin/glEnd
- tu as du mal à penser vbo par manque d'habitude/de pratique

De toute façon, les diplay list couplées à du mode immédiat sont en interne, dans tous les pilotes récents, implémentée avec des vbo et du state tracking (qui est une horreur d'un point de vu bogues et perf)
Donc vu qu'en tant que développeur de ton jeu, tu sais ce que tu fais, en général il faut mieux s'occuper du state tracking soi même avec un scene graph adapté à son rendu et faire du vbo
Ce qui au final ne change pas beaucoup d'un glBegin/glEnd, tu peux très bien le gérer de la sorte avec tes propres appels begin/end et faire un flush à la fin qui balancera le draw de tes vbos.

Bon déjà shared_ptr<> c'est certes bien mais ça n'est sûrement pas un ramasse miettes complet (c'est un peut comme si tu comparais un moteur de voiture avec une voiture complète).

ça c'est de la comparaison !!
un boost::shared_pointer, au même titre qu'un boost::scoped_pointer, boost_intrusive_ptr et autres joyeusetés, ne sont en aucun cas des ramasse miette !!!
Ce sont des outils de gestion de la mémoire adapté à des problèmes particuliers, mais tes miettes ne seront jamais ramassées par eux.
Le mieux, c'est comme au lit, il ne faut pas faire de miette, même en buvant son café…

Bref, coder en C++, c'est dur. Bien plus dur que coder en Java. On devrait coder en C++ uniquement quand on a besoin du gain de performance apporté.

J'ai énormément de mal à coder en Java, alors qu'en C++, les choses s'écrivent simplement pour moi.
Du coup, c'est peut-être pas aussi simple que ça, et ça dépends aussi un peu du dévelopeur, de sa façon de faire, de son expérience, de sa culture, ….

Pour le reste, oui, en c++ généralement, il faut savoir ce que l'on fait.
Ça n'en fait pas un langague plus dur. Et perso, entre une appli en java faite par un dev qui ne sait pas ce qu'il fait mais qui va quand même sortir cas la JVM s'est occupée de ramasser ses merdes miettes et une en C++ avec un codeur qui ne sait pas ce qu'il fait, du coup ça ne sortira pas. Je ne suis pas sur de ce qui est le mieux.

Effectivement, ne dévellopant généralement que pour moi, je n'ai jamais été confronté au soucis de release.

Que fait exactement maven qui tu aimerais trouver dans d'autres outils ?

cmake est assez puissant de ce coté là aussi (bien que je ne l'ai jamais utilisé, donc je manque beaucoup de recul sur les possible soucis) et permet de créer des .deb/.rpm installeurs windows et mac et quelques autres avec seulement un descriptif si tu n'as pas de besoin spécifiques pour une plateforme (c'est du coté de CPack qu'il faut regarder)

Et as-tu consideré le remplacement de autotools par cmake ?

Moi mes projets, c'est c++, cmake, sdl, opengl, qt (pas forcément tout en même temps)

ce que je trouve bien dans cmake, c'est que pour faire un truc simple, c'est simple !

D'ailleurs, aurais-tu un exemple de démo en Qt qui se teste en 2 clics ? Je suis curieux.

Toute la subtilité est de configurer ton environnement pour qu'il réagisse au double click.
Moi comme j'ai pris le pli du simple click, je n'ai malheureusement pas ça sous la main…

Sous valgrind c'est un sapin de noël

De ce coté là, ça n'est pas forcément la faute aux pilotes.
Une partie de la mémoire est touchée par la carte graphique via DMA, et valgrind ne peut pas s'en rendre compte, du coup, il indique une grasse quantité de mémoire utilisée sans être initialisée.

J'ai le même soucis avec des pilotes nvidia.

après, il y a peut-être (sûrement…) d'autres soucis, mais celui là est un faux positif.

Dans mon moteur, le rendu était fait à l'aide d'OpenGL (avec une projection orthogonale)
Donc il me suffisant de dessiner les tuiles visibles (même partiellement) et le moteur OpenGL s'occupait du clipping pour moi.

Si tu dois le faire à la main, un simple clipping sur les coordonnées à l'écran de chaque rectangle de tuile visible avant rendu est suffisant et ça n'est vraiment pas très long en terme de calcul.

Par contre, le gros de l'élagage doit être déjà fait (tu ne dois itérer que sur tes tuiles visibles), mais c'est très simple aussi à coup de division et modulo d'avoir les bornes en i et en j de la grille à dessiner.

ok, ça m'apprendra à ne pas lire jusqu'au bout…
Donc tu affiche TOUTE ta carte à chaque fois ? c'est bien cela ?
Je pense que c'est une mauvaise idée, c'est très simple de n'afficher que la partie visible, avec un tout petit peu d'algorithmique bien encapsulé, une fois écrit, tu n'as plus besoin d'y toucher et tu as un rendu au poil.

Là, la carte fait 250x250 tuiles, ça se passe bien. Mais à 1000x1000 tuiles, ça ralentit sur mon laptop de développement

ça m'étonne tout de même.
1000x1000, même en supposant que tu as besoin de 16 bytes par tuile (ce qui me semble beaucoup)
ça fait quelqueche proche des 16 Mb en mémoire.
Après, je comprends que tu n'as pas forcément envie de consommer autant pour une carte d'un jeu (surtout que la lecture sur disque va prendre du temps) ou que tu compte peut-être passer à une échelle au dessus.

Sais-tu quelle partie fait ramer dans ton cas ?

Je ne l'avais pas compris comme cela, mais effectivement, avec mon mode humour en marche, je comprends ce qu'il a voulu dire et ça me fait sourrire :)