Des explications plus en détails pour le changement de licence, mûrement réfléchi et basé sur 10 ans d'existence de la librairie Ogre et de sa communauté :
- Le monde des consoles de jeux vidéos n'est pas très à l'aise avec les licences. (tout est compilé en statiques avec les librairies de développement propriétaires des fabriquant de consoles) Et tout ceux qui développent des jeux ne veulent pas se priver du marché des consoles....
- Pas vraiment les moyens (temps&argent) de faire respecter la LGPL. Du coup, l'utilité pour Ogre n'est pas concrète, sauf à se priver du marché des consoles de jeux ...
... ne sert à rien si on utilise un moteur 3D. C'est le moteur 3D qui s'occupe de la partie bas-niveau.
La manière dont sont fait les objets 3D et les textures par les artistes, le nombre d'objets à cette instant T et leur disposition, l'utilisation de transparence, etc. sont les facteurs principaux du temps de rendu et de très loin.
Avec n'importe quel moteur 3D, il suffit de tester un rendu de 50 objets de 300 triangles avec 500 textures de 128x128 contre un rendu d'un objet de 15000 avec 1 texture de 2048x2048 en DXT pour le constater de visuellement. Visuellement c'est le même rendu, par contre au niveau performance c'est 50 fps pour le 1er cas contre 1500 fps dans le 2ème...
Le moteur ne va ni modifier tes objets 3D, ni modifier des textures, ni les compresser à ta place...
cycle de rendu.
A moins que le moteur 3D fasse dans l'immediate rendering (a la opengl 1.X glbegin/glend, le moyen age de la 3D), il n'y a plus de cycle de rendu à respecter coté utilisateur, c'est automatique.
Dans les moteur 3D modernes, le travail de rendu est indépendant de la façon dont la scène est décrite par l'utilisateur, puisque en deux temps :
- On décrit la scène (positions des objet, des cameras) pour un instant T
- Le moteur envoit les commandes pour le rendu de cette scène à un instant T.
C'est ce qui permets des traitements basiques, (que font tous les moteurs 3D modernes) comme le tri des objets transparent selon la distance à la caméra, le groupement d'objet par textures, etc. Ces traitements sont indépendants de la façon dont les données sont transmises au moteur.
Ogre est en C++, très orienté objet, avec des motifs de conceptions, avec une documentation très complète, l'objectif principale (notamment lors des arbitrages d'évolution du code) étant la lisibilité et la maintenance du code avant tout, pour que l'utilisateur puisse profiter de toute la flexibilité du moteur 3D.
Ogre offre maintenant aussi l'abstraction de l'API OpenGL ES, donc tourne sur l'Iphone et les PocketPC puissants.
A voir la galerie : http://www.ogre3d.org/gallery/ (avec des Vrai Jeux, c'est à dire commercial avec des gens payés pour le faire...)
Un site/wiki en francais sur Ogre avec beaucoup d'articles/didacticiels/liens sur la communauté Ogre Francophone: http://ogre3d.fr/wiki/Accueil
Les moteurs 3D ne changent pas grand chose de ce coté-là, sauf à apporter des aides pour mieux utiliser la carte 3D, mais il ne peuvent pas optimiser ta 3D à ta place.
Les performance vont surtout dépendre de comment tu utilise la carte 3D...
Pour les performance 3D, il faut lire les papiers, livres et guides chez ATI/NVIDIA à propos des performances, (mots clés dans l'ordre: batch, DXT, Z-pass, etc.) malheureusement quasiment tous en Anglais.
Etudier de près le source code "physic across network" dans les sources en base de cette page. http://www.gaffer.org/articles/
Le code contient tout : "proxy, historique, client side prédication, important moves, serveur de simulation avec perte et lag, etc..."
(l'auteur est celui qui a codé la physique et du réseau dans "Tribes")
- Pas de robustesse de protocole. pas de sequencement. juste un timestamp par paquet, qui permet de décider ce que l'on en fait au niveau du jeu.
- position chassis/roues + quaternion chassis plus roues (roues peut-etre en option et simulé du coté client très simplement). Vitesse et autres données physique si "client side prédiction"
- UDP (une très bonne librairies UDP est ENET utilisé dans cube, sauerbraten) Attention au pièges des librairies (opentnl, hawkNL raknet, etc..). A part gérer les sockets et les threads elle ne sont pas forcement d'une grande aide, notemment pour le lag.
- format binaire, voire compressé. (lzma) Chaque octets conmpte. (pas tellement pour la bande passante, c'est plus pour la surcharge du serveur et/ou la vitesse de traitement des paquets (au niveau OS))
- Chaque envoir "input + dernier changements d'input" + timestamp ("important move") c'est contre les pertes de paquets. (tres frequent sur internet)
- client side predication => il faut pouvoir retourner dans le passer et recommencer à partir de la première divergence avec le serveur. (pour le Lag)
- 20-25Hz maximum pour les envoi réseau depuis le serveur.
- Avoir un serveur de simulation pour les test (qui permet %perte de paquets, lag en ms. le source listé au-dessus a ca aussi.) et qui permet de differencier les erreurs de protocole, socket, os, des erreurs de design.
- Du LOD sur le réseau. N'envoyer les position+quaternions que des voitures dans un champ rapproché limité (plus que la vision). Les autres seront justes un X,Y sur une map 2D de l'utlisateur qui peut se coder sur 16bits.
- plusieurs type de paquet des lents () et des rapides (score, nouveau client, joueurs hors du champ rapproché, etc...). utiliser TCP pour les lents est une option
- si client side prediction, beaucoup de boulot pour etre sur que les résultats seront les memes sur tous les ordis (ne pas oublier un appel à "srand()" par exemple). La mailing liste ODE a des archives complete sur ce sujet.
- Pour le NAT voir la libNAT de john Wattte (le meme que sur la liste ode) et surtout toujours utiliser le meme port.
- Reserver l'ajout des threads après le codage complet du client et serveur (pour debogger tranquille), ou mieux pouvoir le désactiver facilement (#define). les threads sont utiles dès que le nombre de clients devient important (>4) mais rende le deboggage bien plus complexe.
-etc..
(Et accessoirement etre en meilleure place pour le prochain SoC, Connaitre/Aider un projet avant de proposer un sujet SoC augmente fortement les chances d'avoir son application acceptée)
En phase de recherche d'editeurs, le studio a preferé passer sous silence l'utilisation d'un moteur LGPL, pour des raisons psychologique.
Ils en feront état lors de la distibution du jeu.
Maintenant on ne peut acheter que des CPU multi-core.
Intel/Amd/... n'augmenteront les perfs de chaque core que marginalement.
Le seul moyen d'augementer les performance de ce qu'on va programmer, sera d'utiliser le Parallelisme, alors qu'avant on pouvait acheter de plus gros CPU monocore pour aller plus vite...
"mainstream" veut dire utilisé et accepté par tout le monde, industrie et academie.
C++, Java, C#, ruby, python => mainstream
ada, lisp, ocaml => peu utilisé, donc pas mainstream
Ada ne fait malheureusement pas parti du "mainstream".
Qui sait, les "task, "entry", "accept", "requeue", et autres "delay" feraont peut-etre leur coming-back.
Le futur des PC c'est le multi-core, vu que la course au Ghz est enfin finie.
En gros, bientot le seul moyen d'augementer les perfs pour une appli, utiliser les threads....puisqu'on pourra bientot plus acheter de plus gros proc...
Les optimisations de gcc 4 ne peseront pas lourds, face à des compilateurs qui savent gérer les multi-core (vc8, ic9, etc...), notemment par le support d'OPENMP ( http://www.openmp.org/drupal/ )
Vivement l'intégration d'OPENMP dans GCC plutot que de laisser ca en dans une branche inconnue ( http://gcc.gnu.org/projects/gomp/ ).
En tout cas, j'espere que les cours d'algo pour étudiant en ce moment mette plus l'accent qu'avant sur ce problème épineux... sinon "ca va pas etre facile".
Pour les lib dynamiques, depuis gcc4.0 en C++ au moins il y a -fvisibility qui révolutionne la vie des librairies dynamiques :
: http://gcc.gnu.org/wiki/Visibility
Le probleme, outre d'etre géré par des société à but lucratif, est le fait que c'est sensé servir aussi à un paquet d'autre chose que d'empecher le spam des sites et forums. (signature electronique, remplacant de CB, outil de tracage, etc...)
Ici le serveur central n'aurait qu'un et un seul but, j'ai nommée :
" toutes les requêtes que tu aurais passées..."
Le serveur central ne trace rien. Il a la liste des utilisateurs et la liste des sites auquels ils sont inscrit. Le site ne vérifie pas l'authentification pas à chaque fois mais une fois pour toute.
Mais oui, L'idéal étant de le faire gérer par la EFF plutot que par une société à but lucratif...
J'ai toujours révé d'un login/mdp unique pour tous les sites que je consulte. Ca irait plus vite...
On déplace le problème sur le serveur central. En centralisant ca dans un serveur central qui ne fait qu'authentifier la première connexion, apres l'utilisateur est considére comme inscrit dans le site.
Sur le serveur central, l'utilisateur passe une batterie de tests pour determiner son humanité, mais une fois pour toute.
Chaque utilisateur se voit attribuer un nombre de points.
Un site peut reporter un utilisateur comme Spammeur.
Si l'utilisateur est à 0 points => Tous les sites auquels il est inscrit sont notifiés. (il peuvent effacer automatiquement ses traces.)
Tests de reconnaissance auditives (mot, sens, langue), visuelles (distortion de texte, Illusions d'optiques), questionnaire de 50 questions de "bon sens" puisé aléatoirement dans une base de plusieurs milliers. Verif Mail avec utilisation d'une greylist pour verifier les mails, 1 essai max par IP par semaine, etc...
La totale.
On peut se permettre des methodes d'authentification très fortes et combinés, ca me derangerait pas de m'authentifier pendant 10 mn, que ca dégage les spammeurs de tous les forums du web et si c'est une fois pour toutes.
Ameliorer la lecture normale :
-------------------------------------
- Apprendre à lire : ca va de la Position du corps à une relaxation préalable et se mettre en état "d'association sémantique"
- Eduquer les yeux : nombre de mouvements oculaire par ligne (deux max pour un livre de proche). On s'entraine avec des mots de plus en plus grand a lire d'un coup d'oeil, avec un cache et des colonnes de mots de plus en plus grand : C'est de la musculation pure et comme la muscu plus on en fait mieux ca marche, si on arrete la musculation d'oeil, ca part petit a petit, mais on reste au-dessus de précedemment.
Cette amélioration n'implique absolument pas de sauter des mots ou de perdre du sens, au contraire. On lite mieux qu'avant.
Apprendre la lecture partielle rapide:
----------------------------------------------
En plusieurs passes :
- La premiere :zizag pour reperer idée générales, orientation de l'auteur, introduction, parties, sémantique du texte (infromations importantes, annexes, ouvertures sur d'autre sujets...), conclusion et meme le découpage de phrase avec priorité d'importance
- La deuxième passe :
- lire l'important reperé dans la premiere passe.
- Pause de réflexion sur le texte (sens, contradictions, apports, confrontation experience personnelle)
Et on repete les passes jusqu'a comprehension sure du texte. Necessite de l'entraienement mais c'est "une fois pour toute". Pour l'apprendre il faut des exercices prevus pour ca, texte suivi d'interrogation pour voir si on a saisi, histoire de calibrer le nombre de passes et le reperage de mots.
Inconsciemment ca aide aussi la lecture normale pour la compréhension.
Cette amelioration peut impliquer de sauter des mots ou de perdre du sens, mais plus on s'est exercé, plus la marge est faible, voire inexistante, surtout si on s'applique a ne pas limiter le nombre de passes à 2 (cas le plus fréquent.).
Conclusion:
--------------
Je recommande tout ca a tout le monde. C'est ca apprendre a lire sémantiquement. C'est vraiment pas un gadget.
Lire partiellement puis ensuite lire normalement, ameliore énormement la compréhension et les apports d'un texte. (la lecture partielle rapide ne s'applique pas à un roman... sauf pour les lecteurs allergiques aux de description longues...)
Pour un enfant ou un adulte dyslexique ca le sauver, les dyslexiques sont meilleurs que les "non-dislexyque" en lecture partielle rapide et beaucoup moins bon en lecture normale, jusqu'a etre incapable de lire "normalement" dans certains cas.
Pour un DS, partiel, ou tout autre évaluation scolaire, c'est hyper pratique :
Lire partiellement tout le sujet puis ensuite lire normalement, ameliore en plus énormement la compréhesion et évite de fait de faire hors sujet. Et on a souvent fini de lire tout le sujet au moment ou les sujets viennent juste de finir d'etre distribuée (sauf si on est le dernier.).
Pour les étudiants, l'écriture rapide est vraiment utile aussi. On peut gagner jusqu'a 3/4h sur un devoir de 4h. (calculer vous meme le nombre de lettre ecrites par minute, augmenter le de qq lettre, puis calculer sur 6000 lettres, la différence est vite surprenante.
On ecrit plus lisiblement aussi, ce qui influe aussi sur la note.
# Schopenhauer Bot Prize
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Comment réfuter. Évalué à 2.
s/Shopenhauer/Schopenhauer/
http://imaginationforpeople.org/fr/project/schopenhauer-bot-prize/
[^] # Re: et change de licence (LGPL → MIT).
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche OGRE 3D: Sortie de la version 1.7 (Cthugha). Évalué à 6.
- Le monde des consoles de jeux vidéos n'est pas très à l'aise avec les licences. (tout est compilé en statiques avec les librairies de développement propriétaires des fabriquant de consoles) Et tout ceux qui développent des jeux ne veulent pas se priver du marché des consoles....
- Pas vraiment les moyens (temps&argent) de faire respecter la LGPL. Du coup, l'utilité pour Ogre n'est pas concrète, sauf à se priver du marché des consoles de jeux ...
[^] # Re: Projets réalisés avec Ogre
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Conférence sur le moteur 3D "Ogre" le 12 novembre 2009. Évalué à 5.
La manière dont sont fait les objets 3D et les textures par les artistes, le nombre d'objets à cette instant T et leur disposition, l'utilisation de transparence, etc. sont les facteurs principaux du temps de rendu et de très loin.
Avec n'importe quel moteur 3D, il suffit de tester un rendu de 50 objets de 300 triangles avec 500 textures de 128x128 contre un rendu d'un objet de 15000 avec 1 texture de 2048x2048 en DXT pour le constater de visuellement. Visuellement c'est le même rendu, par contre au niveau performance c'est 50 fps pour le 1er cas contre 1500 fps dans le 2ème...
Le moteur ne va ni modifier tes objets 3D, ni modifier des textures, ni les compresser à ta place...
cycle de rendu.
A moins que le moteur 3D fasse dans l'immediate rendering (a la opengl 1.X glbegin/glend, le moyen age de la 3D), il n'y a plus de cycle de rendu à respecter coté utilisateur, c'est automatique.
Dans les moteur 3D modernes, le travail de rendu est indépendant de la façon dont la scène est décrite par l'utilisateur, puisque en deux temps :
- On décrit la scène (positions des objet, des cameras) pour un instant T
- Le moteur envoit les commandes pour le rendu de cette scène à un instant T.
C'est ce qui permets des traitements basiques, (que font tous les moteurs 3D modernes) comme le tri des objets transparent selon la distance à la caméra, le groupement d'objet par textures, etc. Ces traitements sont indépendants de la façon dont les données sont transmises au moteur.
# Infos et liens complémentaires
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Conférence sur le moteur 3D "Ogre" le 12 novembre 2009. Évalué à 3.
Ogre offre maintenant aussi l'abstraction de l'API OpenGL ES, donc tourne sur l'Iphone et les PocketPC puissants.
A voir la galerie : http://www.ogre3d.org/gallery/ (avec des Vrai Jeux, c'est à dire commercial avec des gens payés pour le faire...)
Un site/wiki en francais sur Ogre avec beaucoup d'articles/didacticiels/liens sur la communauté Ogre Francophone: http://ogre3d.fr/wiki/Accueil
Des projets open-source complets sous Linux à tester:
- Rigs of Rods http://rigsofrods.com/ (Jeu de voitures)
- Ultima Iris : http://ghoulsblade.schattenkind.net/iris/wiki/index.php/Main(...) (Client Ultima Online)
- PlayerStage : http://sourceforge.net/projects/playerstage/ (Application de robotique)
[^] # Re: Projets réalisés avec Ogre
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Conférence sur le moteur 3D "Ogre" le 12 novembre 2009. Évalué à 2.
Les moteurs 3D ne changent pas grand chose de ce coté-là, sauf à apporter des aides pour mieux utiliser la carte 3D, mais il ne peuvent pas optimiser ta 3D à ta place.
Les performance vont surtout dépendre de comment tu utilise la carte 3D...
Pour les performance 3D, il faut lire les papiers, livres et guides chez ATI/NVIDIA à propos des performances, (mots clés dans l'ordre: batch, DXT, Z-pass, etc.) malheureusement quasiment tous en Anglais.
A lire pour optimiser un projet Ogre vite fait:
http://www.ogre3d.org/wiki/index.php/Optimisation_checklist
(le WIKI Ogre est par ailleurs une mine d'information)
# C'est le probleme le plus complexe...
Posté par tuan kuranes (site web personnel) . En réponse au journal Rendre un jeu jouable en réseau. Évalué à 10.
http://www.gaffer.org/articles/
Le code contient tout : "proxy, historique, client side prédication, important moves, serveur de simulation avec perte et lag, etc..."
(l'auteur est celui qui a codé la physique et du réseau dans "Tribes")
Si tu es anglophone, il faut lire absolument tout ces articles :
http://www.ogre3d.org/wiki/index.php/External_Links#Articles
(Sinon ca va vraiment être dur)
Sinon, en gros:
- Pas de robustesse de protocole. pas de sequencement. juste un timestamp par paquet, qui permet de décider ce que l'on en fait au niveau du jeu.
- position chassis/roues + quaternion chassis plus roues (roues peut-etre en option et simulé du coté client très simplement). Vitesse et autres données physique si "client side prédiction"
- UDP (une très bonne librairies UDP est ENET utilisé dans cube, sauerbraten) Attention au pièges des librairies (opentnl, hawkNL raknet, etc..). A part gérer les sockets et les threads elle ne sont pas forcement d'une grande aide, notemment pour le lag.
- format binaire, voire compressé. (lzma) Chaque octets conmpte. (pas tellement pour la bande passante, c'est plus pour la surcharge du serveur et/ou la vitesse de traitement des paquets (au niveau OS))
- Chaque envoir "input + dernier changements d'input" + timestamp ("important move") c'est contre les pertes de paquets. (tres frequent sur internet)
- client side predication => il faut pouvoir retourner dans le passer et recommencer à partir de la première divergence avec le serveur. (pour le Lag)
- 20-25Hz maximum pour les envoi réseau depuis le serveur.
- Avoir un serveur de simulation pour les test (qui permet %perte de paquets, lag en ms. le source listé au-dessus a ca aussi.) et qui permet de differencier les erreurs de protocole, socket, os, des erreurs de design.
- Du LOD sur le réseau. N'envoyer les position+quaternions que des voitures dans un champ rapproché limité (plus que la vision). Les autres seront justes un X,Y sur une map 2D de l'utlisateur qui peut se coder sur 16bits.
- plusieurs type de paquet des lents () et des rapides (score, nouveau client, joueurs hors du champ rapproché, etc...). utiliser TCP pour les lents est une option
- si client side prediction, beaucoup de boulot pour etre sur que les résultats seront les memes sur tous les ordis (ne pas oublier un appel à "srand()" par exemple). La mailing liste ODE a des archives complete sur ce sujet.
- Pour le NAT voir la libNAT de john Wattte (le meme que sur la liste ode) et surtout toujours utiliser le meme port.
- Reserver l'ajout des threads après le codage complet du client et serveur (pour debogger tranquille), ou mieux pouvoir le désactiver facilement (#define). les threads sont utiles dès que le nombre de clients devient important (>4) mais rende le deboggage bien plus complexe.
-etc..
# Liens direct vers la présentation au format video lisible sur GNU/Linux
Posté par tuan kuranes (site web personnel) . En réponse au journal Vous pensez connaître l'état du monde ?. Évalué à 10.
[^] # Re: Idée recue numéro 1
Posté par tuan kuranes (site web personnel) . En réponse au journal Vous pensez connaître l'état du monde ?. Évalué à 1.
http://www.ted.com/tedtalks/
[^] # Re: Quelqu'un a des nouvelles d'axiom3d?
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de Ogre3d 1.2. Évalué à 2.
OgreDotNet est très actif :
http://www.ogre3d.org/phpBB2addons/viewforum.php?f=1
Et un petit nouveau vient de sortir :http://www.ogre3d.org/wiki/index.php/MOGRE
# Communauté francophone
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de Ogre3d 1.2. Évalué à 1.
http://ogre3d.free.fr/modules/news/
[^] # Re: SoC
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de Ogre3d 1.2. Évalué à 1.
http://www.ogre3d.org/wiki/index.php/HelpRequested
(Et accessoirement etre en meilleure place pour le prochain SoC, Connaitre/Aider un projet avant de proposer un sujet SoC augmente fortement les chances d'avoir son application acceptée)
[^] # Re: Double licence
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de Ogre3d 1.2. Évalué à 2.
[^] # Re: Jeu proprio utilisant Ogre
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de Ogre3d 1.2. Évalué à 4.
http://www.ogre3d.org/wiki/index.php/Projects_using_OGRE
Notemment comme dernier jeu à succès commercialisé le jeu d'aventures "Ankh".
Sinon un jeu gratis à tester absolument "Stunt Playground" (qui cherche un dev sous Linux pour le portage.)
[^] # Re: Jeu proprio utilisant Ogre
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de Ogre3d 1.2. Évalué à 6.
Ils en feront état lors de la distibution du jeu.
[^] # Re: Jeu proprio utilisant Ogre
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de Ogre3d 1.2. Évalué à 3.
Ils en seront obligés quand il le distribuerons et encore, dans la doc, pas forcement en premiere page du site web.
[^] # Re: Ah, ben zut...
Posté par tuan kuranes (site web personnel) . En réponse au journal Free Lunch is over : Video. Évalué à 2.
Intel/Amd/... n'augmenteront les perfs de chaque core que marginalement.
Le seul moyen d'augementer les performance de ce qu'on va programmer, sera d'utiliser le Parallelisme, alors qu'avant on pouvait acheter de plus gros CPU monocore pour aller plus vite...
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 1.
"mainstream" veut dire utilisé et accepté par tout le monde, industrie et academie.
C++, Java, C#, ruby, python => mainstream
ada, lisp, ocaml => peu utilisé, donc pas mainstream
Ada ne fait malheureusement pas parti du "mainstream".
Qui sait, les "task, "entry", "accept", "requeue", et autres "delay" feraont peut-etre leur coming-back.
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 1.
http://gcc.gnu.org/projects/gomp/
[^] # Re: Toujours pas l'intégration de GOMP...
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 10.
# Toujours pas l'intégration de GOMP...
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 10.
En gros, bientot le seul moyen d'augementer les perfs pour une appli, utiliser les threads....puisqu'on pourra bientot plus acheter de plus gros proc...
Quelques docs pour ceux qui n'ont pas suivi :
- The Free Lunch Is Over de Herb Sutter (comité de normalisation du c++ : http://www.gotw.ca/publications/concurrency-ddj.htm )
- Managing Concurrency: Latent Futures, Parallel Lives ( http://www.gamearchitect.net/Articles/ManagingConcurrency1.h(...) )
Les optimisations de gcc 4 ne peseront pas lourds, face à des compilateurs qui savent gérer les multi-core (vc8, ic9, etc...), notemment par le support d'OPENMP ( http://www.openmp.org/drupal/ )
Vivement l'intégration d'OPENMP dans GCC plutot que de laisser ca en dans une branche inconnue ( http://gcc.gnu.org/projects/gomp/ ).
En tout cas, j'espere que les cours d'algo pour étudiant en ce moment mette plus l'accent qu'avant sur ce problème épineux... sinon "ca va pas etre facile".
[^] # Re: A propos des optimisations de code
Posté par tuan kuranes (site web personnel) . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 10.
Pour les lib dynamiques, depuis gcc4.0 en C++ au moins il y a -fvisibility qui révolutionne la vie des librairies dynamiques :
: http://gcc.gnu.org/wiki/Visibility
[^] # Re: Serveur Central
Posté par tuan kuranes (site web personnel) . En réponse au journal des idées pour éviter la création automatique de compte par des bots ?. Évalué à 2.
Et par le nouveau truc de sir bill gates cf : http://www.theinquirer.net/?article=29751
Le probleme, outre d'etre géré par des société à but lucratif, est le fait que c'est sensé servir aussi à un paquet d'autre chose que d'empecher le spam des sites et forums. (signature electronique, remplacant de CB, outil de tracage, etc...)
Ici le serveur central n'aurait qu'un et un seul but, j'ai nommée :
L'identification humaine
[^] # Re: Serveur Central
Posté par tuan kuranes (site web personnel) . En réponse au journal des idées pour éviter la création automatique de compte par des bots ?. Évalué à 1.
Le serveur central ne trace rien. Il a la liste des utilisateurs et la liste des sites auquels ils sont inscrit. Le site ne vérifie pas l'authentification pas à chaque fois mais une fois pour toute.
Mais oui, L'idéal étant de le faire gérer par la EFF plutot que par une société à but lucratif...
# Serveur Central
Posté par tuan kuranes (site web personnel) . En réponse au journal des idées pour éviter la création automatique de compte par des bots ?. Évalué à 2.
On déplace le problème sur le serveur central. En centralisant ca dans un serveur central qui ne fait qu'authentifier la première connexion, apres l'utilisateur est considére comme inscrit dans le site.
Sur le serveur central, l'utilisateur passe une batterie de tests pour determiner son humanité, mais une fois pour toute.
Chaque utilisateur se voit attribuer un nombre de points.
Un site peut reporter un utilisateur comme Spammeur.
Si l'utilisateur est à 0 points => Tous les sites auquels il est inscrit sont notifiés. (il peuvent effacer automatiquement ses traces.)
Tests de reconnaissance auditives (mot, sens, langue), visuelles (distortion de texte, Illusions d'optiques), questionnaire de 50 questions de "bon sens" puisé aléatoirement dans une base de plusieurs milliers. Verif Mail avec utilisation d'une greylist pour verifier les mails, 1 essai max par IP par semaine, etc...
La totale.
On peut se permettre des methodes d'authentification très fortes et combinés, ca me derangerait pas de m'authentifier pendant 10 mn, que ca dégage les spammeurs de tous les forums du web et si c'est une fois pour toutes.
# 2 types de lecture rapide, ca prete tjrs à confusion
Posté par tuan kuranes (site web personnel) . En réponse au journal La lecture rapide : qu'en penser ?. Évalué à 4.
-------------------------------------
- Apprendre à lire : ca va de la Position du corps à une relaxation préalable et se mettre en état "d'association sémantique"
- Eduquer les yeux : nombre de mouvements oculaire par ligne (deux max pour un livre de proche). On s'entraine avec des mots de plus en plus grand a lire d'un coup d'oeil, avec un cache et des colonnes de mots de plus en plus grand : C'est de la musculation pure et comme la muscu plus on en fait mieux ca marche, si on arrete la musculation d'oeil, ca part petit a petit, mais on reste au-dessus de précedemment.
Cette amélioration n'implique absolument pas de sauter des mots ou de perdre du sens, au contraire. On lite mieux qu'avant.
Apprendre la lecture partielle rapide:
----------------------------------------------
En plusieurs passes :
- La premiere :zizag pour reperer idée générales, orientation de l'auteur, introduction, parties, sémantique du texte (infromations importantes, annexes, ouvertures sur d'autre sujets...), conclusion et meme le découpage de phrase avec priorité d'importance
- La deuxième passe :
- lire l'important reperé dans la premiere passe.
- Pause de réflexion sur le texte (sens, contradictions, apports, confrontation experience personnelle)
Et on repete les passes jusqu'a comprehension sure du texte. Necessite de l'entraienement mais c'est "une fois pour toute". Pour l'apprendre il faut des exercices prevus pour ca, texte suivi d'interrogation pour voir si on a saisi, histoire de calibrer le nombre de passes et le reperage de mots.
Inconsciemment ca aide aussi la lecture normale pour la compréhension.
Cette amelioration peut impliquer de sauter des mots ou de perdre du sens, mais plus on s'est exercé, plus la marge est faible, voire inexistante, surtout si on s'applique a ne pas limiter le nombre de passes à 2 (cas le plus fréquent.).
Conclusion:
--------------
Je recommande tout ca a tout le monde. C'est ca apprendre a lire sémantiquement. C'est vraiment pas un gadget.
Lire partiellement puis ensuite lire normalement, ameliore énormement la compréhension et les apports d'un texte. (la lecture partielle rapide ne s'applique pas à un roman... sauf pour les lecteurs allergiques aux de description longues...)
Pour un enfant ou un adulte dyslexique ca le sauver, les dyslexiques sont meilleurs que les "non-dislexyque" en lecture partielle rapide et beaucoup moins bon en lecture normale, jusqu'a etre incapable de lire "normalement" dans certains cas.
Pour un DS, partiel, ou tout autre évaluation scolaire, c'est hyper pratique :
Lire partiellement tout le sujet puis ensuite lire normalement, ameliore en plus énormement la compréhesion et évite de fait de faire hors sujet. Et on a souvent fini de lire tout le sujet au moment ou les sujets viennent juste de finir d'etre distribuée (sauf si on est le dernier.).
Pour les étudiants, l'écriture rapide est vraiment utile aussi. On peut gagner jusqu'a 3/4h sur un devoir de 4h. (calculer vous meme le nombre de lettre ecrites par minute, augmenter le de qq lettre, puis calculer sur 6000 lettres, la différence est vite surprenante.
On ecrit plus lisiblement aussi, ce qui influe aussi sur la note.