Rémi Hérilier a écrit 205 commentaires

Enlève ton masque Georges, on t'as reconnu.

/me -> []

Ogre3D est un moteur gérant l'affichage, les données graphiques et ce qui touche aux collisions et à la physique, il lui manque le son et bien d'autre chose.

L'idée de Nicolas Martyanoff est de faire une API assez bas niveau (comparé à un moteur) qui fasse office de surcouche à, par exemple, OpenGL/OpenAL/Lua/ODE/autre pour définir un ensemble cohérent exploitable par des personnes/sociétés pour qu'elles développent leur propre moteur de jeu ... bref, un équivalent à DirectX.

Ta fougue semble te faire mélanger beaucoup de choses. OpenGL est une API graphique bas niveau, pas un middleware comme peut l'être Renderware (DirectX, lui, se place à mi chemin tout en étant plus proche du middleware) donc merci de comparer ce qui est comparable.


Tu veux refaire un système physique alors qu'il existe l'excellent ODE : http://www.ode.org/ ?
Tu veux refaire un système sonore alors qu'il existe OpenAL : http://www.openal.org/ ?
tu comptes aussi réinventer libcal3D (http://cal3d.sourceforge.net/ ) ?
Pour les systèmes de datapack, cherches avec ton moteur de recherche préféré et tu en trouvera à la pelle.

Pour le scriptage, Lua devrait te plaire.

Si ceux-là ne te plaisent pas, tu en trouveras d'autre plus à ta convenance.


Bien-sûr, c'est du boulot, raison pour laquelle ça n'existe pas...

J'adore cette phrase ... pourquoi cela n'existe pas ? Parce qu'il n'y a que les sociétés commerciales qui peuvent se permettre un tel investissement. Si les dev d'Ogre3D utilisent au maximum des bibliothèques tierces, ce n'est pas pour rien. Il est de loin plus efficace de s'appuyer sur une communauté déjà existante que sur celle de son projet.

DirectX propose tout de base (pas de physique pourtant, cénul) mais dire qu'il n'y a rien en face, je trouve ça plutôt insultant pour tous les gens qui bossent dessus et avec.


Je m'excuse pour le rentre dedans mais il te faut revenir sur Terre et retrouver une objectivité décente. Toutefois, je me permet d'hasarder quelques conseils :

1/ KISS. Si tu fais une API trop complexe/figée/autre, la migration vers ton API n'en sera plus que douloureuse pour les dev intéressés. Il te faut donc un système alliant à la fois puissance, évolutivité et souplesse.

2/ Puisque tu es assez remonté contre l'absence de doc, fais en une bien avec des tutoriels (qui marchent:). Tu risques de comprendre pourquoi il n'y en a peu et pourquoi certaines bonnes idées restent méconnues.


Pour conclure, il y a, à mon avis, largement de quoi répondre aux besoins de chacuns. Mais ce qui manque surtout, c'est de la communication. Qui sait qu'Unreal tournament utilise OpenAL ? Qui sait que les Baldur's Gate utilise Lua comme langage de script ? Il doit y avoir pleins d'autres cas mais aucun n'est correctement valorisé.


Bon, j'pars fouiller dans mes répertoires si je peux trouver du code suceptible de vous être utile :)

rem sur #codefr@freenode

OpenGL est un standard géré par l'ARB, pas par une seule société (même si SGI en est à l'origine) donc il y a peu de chance qu'OpenGL disparaisse.

Avec l'histoire de Vista qui ne permettra(it) pas une adéquation parfaite entre l'interface graphique et OpenGL, j'ai quand même quelques craintes mais je reste relativement confiant dans les utilisateurs professionnels car je vois mal des sociétés passer de Maya (qui n'est qu'OpenGL) à 3dsMax (qui supporte aussi Direct3D) ... je les vois plus passer sous un Linux. De même pour celles qui sont encore sous des stations Unix et qui renouvèlent leur parcs avec des PCs pour des raisons de puissance/prix. Il vaut mieux un Unix (et donc Linux) pour minimiser les changements d'habitudes. Pour moi, le rejet d'OpenGL par Ms est une jolie balle tirée dans leur pied pour ce qui est du secteur professionnel.


J'ai du mal à voir SGI se faire racheter par un fondeur de processeurs graphiques comme Nvidia. D'ailleurs, à une époque, il y avait des rumeurs de rachat de la division graphique de SGI par Nvidia (qui coincide avec le changement de Silicon Graphics en SGI). En tout cas, il y a des accords entre eux puisque les systèmes graphiques VPro utilisés par SGI pour certaines de leur stations viennent de chez Nvidia (par contre, qui a fait quoi, je ne sais pas):

bon, au dodo maintenant /o\

Pour compléter ce qui a été dit dans les autres posts, il faut quand même garder à l'esprit qu'OpenGL n'a pas grand chose à voir avec Direct3D. En effet, ce dernier existe principalement pour le jeu. En revanche, OpenGL est présent sur la totalité des stations de travail (IBM, Sun, SGI & consort) et les applications de simulation ou de visualisation reposent fortement dessus. Donc à mon avis, la mort d'OpenGL n'est pas pour demain.

Pour ce qui est de l'évolution, tout dépend aussi de l'architecture des ordinateurs. Du peu que je connais des stations que j'ai cotoyées lors de mes études, j'aurais plutôt tendance à dire que l'on a régressé avec les cartes graphiques embarquant leur propre mémoire. On a certes gagné en rapidité mais on a aussi beaucoup perdu en fonctionnalité. En effet, sur les machines à mémoire unifiée, les vertex arrays et les textures étaient d'une grande puissance : le programme modifiait les buffers et les modifications se répercutaient immédiatement à l'écran. Pour retrouver cette puissance, les constructeurs (puis l'ARB) ont dû sortir les render to texture ou les VBO pour rerattraper le retard (tout comme avec la récente GLX_EXT_texture_from_pixmap utilisée par Xgl). Et nous en sommes encore loin puisqu'il y a toujours besoin de faire des transferts entre mémoire centrale et mémoire graphique. Tout ça pour dire que la seule grande innovation depuis belles lurettes est les shaders.

Pour poursuivre sur les shaders, Direct3D a suivit le matériel (enfin ... celui accessible aux utilisateurs de PCs), on a donc eu plusieurs versions et révisions pour les shaders. Mystérieusement pour OpenGL, on a 1 seule version (avec quand même des révisions mineures). Mes drivers Nvidia me disent "vous avez les shaders de disponible !", je dis "youpi \o/" et pourtant ma gffx5200 supporte partiellement les buffers en flottant et les instructions de saut en sont absentes. Il a fallu donc qu'ATI, Nvidia & les autres arrivent à implémenter les spec d'OpenGL/GLSL dans leurs GPU et cela leur a pris du temps (3 générations de GPU pour Nvidia). Pendant ce temps là, OpenGL stagnait car personne ne l'implémentait à 100% en hard ou n'avait pas besoin de plus.

OpenGL est certes vieux mais on ne change pas une API éprouvée du jour au lendemain. D'ailleurs 3DLabs s'était pris une belle claque en 2001/2002 car ils avaient réfléchi sur un OpenGL 2.0 où il le remettait entièrement à plat. Mais bon, les specs ont disparu du web et rien ne semblent présager leur retour sur le devant de la scène ; c'est triste ...

Dans ton énumération des API reprenant l'approche d'OpenGL pour des domaines plus spécifiques, tu oublies OpenAL pour le son (et qui pourra sûrement t'intéresser quand tu t'attaqueras au son dans ton jeu:)

À propos de ton jeu, quelle méthode utilises tu pour le terrain ? heighmap avec un quadtree ? octree ? ROAM ? CLOD ? j'avoue avoir laché un "merde ! y dit pas quel algo il utilise" O:-)

mes 2¢ ... allez ! 3¢ vu le nombre de caractères :]

Je ne trouve pas ce qu'il y ait quelquechose de comique dans tout ça, de l'originalité tout au plus.

Faire le lien entre un tapis et une manette de jeu vu la grande ressemblance entre ces deux types de périphériques est effectivement à la portée de tout le monde. En revanche, adapter quelquechose d'aussi pauvre (comparé à la paire clavier-souris) à une utilisation radicalement différente tout en conservant une interactivité intuituive, ce n'est plus à la portée de tous.

En dehors de faire faire de l'exercice, cela peut aussi être utilable dans le cadre de rééducation ou le cas de personne à qui les clavier-souris sont inaccessibles (et pour qui un système de suivie du regard est hors de portée).

C'est vrai que comparé aux écrans multi-tactiles, ça fait plus que fantaisiste mais bon, si le tapis trouve son créneau, on en trouvera plus que ce type d'écran.

<humour>
Windows va gagner en efficacité puisqu'il va passer d'un doigt à deux pieds \o/
</humour>

Pour ce qui est du jeu, tu as de l'OpenGL dans .... seulement les jeux PC/Mac

Les Xbox ont DirectX, la PS2 a un truc à sa sauce, la GameCube aussi. Il faut attendre la PS3 pour avoir OpenGL/ES ... un peu triste.

Ensuite, quand on regarde la portabilité des jeux entre plateforme, soit les développeurs passent par un middleware (comme Renderware) s'ils souhaitent taper tout azimut (mais au final, ils ne développent ni avec DirectX ni avec OpenGL), soit ils se cantonnent à une seule (GameCube, PS2 ou PC/Win+Xbox).

Ça ne m'étonne donc pas qu'OpenGL soit délaissé (à mon grand regret) dans l'univers des jeux vidéos.

Le processeur ne fait malheureusement pas tout. Les architectures à mémoire unifiée que SGI a développé pour ses stations ne sont pas comparable avec celle de nos PC. À la rigueur, les portables qui utilisent une partie de la mémoire centrale pour le framebuffer, les textures & cie s'en rapproche mais ne tiennent pas longtemps la comparaison.

En effet, sur ces portables, le processeur, le chipset et la mémoire sont sur le même bus et le système graphique passe par l'AGP/PCIe (et donc le chipset) pour accéder à la mémoire centrale. il en est de même pour toutes les E/S.

Sur les SGI Visual Workstation (la gamme à base de proc Intel), le proc, la proc graphique, le proc sonore ainsi que le chipset sont en attaque directe sur le controleur mémoire et seules les E/S genre clavier/souris/ddur/carte fille sur PCI doivent passer par le chipset. De plus les accès mémoire sont fait via un crossbar, système qui permet à chaque composant d'accéder en même temps à la mémoire (avec bien sûr des cas particuliers de conflit qui sont gérés en hard).

Je n'ai malheureusement pas d'exemples concrets à te donner car il n'existe pas beaucoup de doc sur ces stations (trop chères comparées à une gros PC). Mais je peux t'en donner un sur les SGI O2 qui ont une architecture dont s'inspire celle des SGI Visual Workstation.

Comme la mémoire est partagée, une application qui passe un buffer à OpenGL pour définir une texture ne fait que donner l'adresse mémoire (il n'y a donc pas de recopie dans la mémoire graphique, d'où un certain gain). De plus, la mémoire étant partagée, une modification du buffer par l'application se répercute immédiatement à l'écran puisqu'il n'y a pas de transfert à effectuer. Utiliser une vidéo comme texture est de facto très facile à réaliser et n'est pas gourmand pour un sous (à part le décodage bien sûr;)

Ressortir une telle architecture avec les possibilités actuelles (HyperTransport & cie) permettrait sans doute de redonner un sérieux souffle au PC mais serait-ce encore un PC ?

SGI utilise bien OpenGL pour l'affichage de son serveur X, ça a donc déjà été testé/éprouvé. Par contre il est clair que l'archi d'un PC n'a rien à avoir avec celle d'une station SGI ...

Je sais, j'ai fait mon mea culpa mea coule plus après avoir écrit mon post du 23/02/2006 à 15:49 ;)

/me qui retourne se cacher

Je suis bon pour faire mon mea culpa quant à ma remarque sur la terminologie, j'ai effectivement tort ... ça m'apprendra à me baser sur des souvenirs de lectures vieilles de 8 ans /o\

Donc l'errata de mon roman est le suivant : remplacer "application(s) X" par "client(s) X", "serveur X" par "Xlib" et "client X" par "serveur X".

source : http://fr.wikipedia.org/wiki/X_Window

Xgl n'est qu'une architecture client : convertir les primitives d'affichage de X en appels OpenGL, rien à voir avec le serveur (qui est géré par la Xlib). Par contre, GLX devrait certainement céder sa place à EGL (en supposant bien sûr que EGL se démocratise). Mais seul l'avenir le dira (attendons de voir fleurir EGLwin, EGLmac, EGLfb et bien sûr EGLx =)

La véracité des perfs, ça se discutent ;)

Mais dans l'absolu, Xgl doit effectivement être plus rapide puisqu'il redirige tout vers OpenGL. Par contre, quand les devs de AIGLX trouveront l'idée permettant de balancer le rendu 2D vers OpenGL, on devrait retrouver sensiblement les même perfs mais avec le client Xorg générique et non un client spécifique.

\o/ ça ne m'a pas pris 3h \o/

Dans la terminologie de X, le serveur X s'occupe la couche de communication (qui permet la transparence réseau) et le client s'occupe des entrées/sorties (clavier/souris/écran/autre). Donc là où on veut utiliser une application X, il faut obligatoirement un serveur X et là où on veut interagir avec une application X, il faut un client X (qui lance forcement un serveur X). Et où est ce serveur X ? c'est /usr/X11R6/lib/libX11.so :)


Pourquoi modifier le client Xorg ? Tout simplement parce que son architecture ne permet pas de faire ce qu'apporte AIGLX et Xgl : l'utilisation d'OpenGL pour la composition. Il faut l'extension GLX_EXT_texture_from_pixmap.

L'approche de Xgl est de rediriger les primitives 2D vers glitz (et donc OpenGL) alors que celle de AIGLX est de mettre au même niveau OpenGL et les pilotes graphiques du client X (puisqu'ils peuvent partager des XPixmaps). AIGLX est plus léger en terme de modification mais une vieille application en Xaw ne fera que de la 2D (au niveau du pilote graphique) alors que Xgl remet à plat beaucoup de choses mais permet d'avoir une utilisation de la 3D à tous les niveaux (même si certains toolkits ont moins d'intermédiaire que d'autres). Mais d'une manière générale, Xgl et AIGLX permettent bien de faire exactement la même chose. Personnellement, je ne vote ni pour Xgl ni pour AIGLX car je pense qu'un mélange des 2 est possible =)


X est lent car :
- la Xlib a des appels synchrones que les specs disent asynchrones (voir Xcb pour la réécrire de la Xlib pour corriger ce problème).
- certaines extensions sont exécutées par le processeur (donc besoin d'un processeur puissant puisqu'on a les applications *et* le client X qui le solicitent).
- autres problèmes dus à des pilotes buggués et/ou à code fermés.


Tu as entièrement raison, Xgl est un client X qui utilise OpenGL pour l'affichage. En revanche, je ne comprend pas ta phrase suivante :

Xglx est un client X et a donc besoin d'un serveur X pour fonctionner, hors le but d'un serveur X se basant sur OpenGL? c'est de ne pas à avoir à écrire de driver X.... vous comprenez la connerie ?

Tu confonds un peu tout. où est la "connerie" d'utiliser OpenGL dans le client X ? Le serveur X ne fait que gérer les communications entre application X et client X. Utiliser à distance une application Gtk+ (Gtk+ 2.8 avec glitz pour l'affichage) est toujours possible. Bref, tout va bien et rien n'a changé pour l'utilisateur. Et pourquoi ? Tout simplement parce que la couche basse (du toolkit ou Xglx lui même) à appelé GLX pour ouvrir un contexte GLX sur la machine cliente.

Pour EGL, c'est encore autre chose. EGL est une uniformisation de GLX/WGL/AGL (et d'autres s'ils existent). Donc on a une unique API pour gérer des contextes OpenGL (et donc le rendu). Après, que l'implémentation utilise X, MacOSX ou Ms Windows pour permettre leurs interactions, ce n'est plus un problème puisqu'une unique API permet de s'abstraire de l'environnement dans lequel on utilise l'application.

Si mon raisonnement etait erroné - càd qu'EGL est une couche à peine moins basse qu'OpenGL mais totalement indépendante de tout système de fenêtrage - il serait donc possible à X de s'appuyer dessus pour l'affichage mais le problème de l'absence de tranparence réseau impliquerait le développement d'une couche dans X pour le permettre ... on vient de réinventer GLX sauf qu'il s'appelerait EGLX \o/

Pour s'en convaincre, il suffit de comparer les specs de GLX et d'EGL ... elles se ressemblent beaucoup trop pour ne pas permettre les mêmes possibilités (la transparence réseau entre autre). En l'occurrence la même séparation entre un "état client" et un "état serveur" qui permet justement à GLX d'encapsuler les appels OpenGL dans le protocole X.


OpenGL/ES apparait effectivement comme étant une version pour embarqué d'OpenGL. Personnellement, je vois surtout une "remise à plat" d'OpenGL - ou plutôt une correspondance entre OpenGL/ES 1.0 et une version OpenGL 1.x donnée (je n'ai pas lu en profondeur les specs d'OpenGL/ES) - De plus, OpenGL/ES est montré comme étant une API 2D/3D totalement indépendante ... OpenGL l'est à l'origine (et ça doit remonter à IrisGL son ancêtre). D'ailleurs, pourquoi la libGL est-elle dans /usr/lib et non dans /usr/X11R6/lib ?

ayé, fini ^_^

ps: j'espère ne pas trop faire écho avec d'autres posts ... il y a presque 3h entre le début et la fin de mon roman /o\

Non, je dis juste que les specs d'OpenGL n'impose aucunes dépendances à quoi que ce soit. C'est à GLX de faire le lien entre les primitives de X11 et OpenGL et non à OpenGL d'utiliser directement X11. Ceci étant, entre théorie et pratique, y'a souvent une belle différence ;)

En utilisant une architecture à mémoire partagée (comme sur les bonnes vieilles SGI O2 et cie), des bus HyperTransport (un pour le CPU, un pour la GPU, un pour les E/S et un pour la RAMDAC) et un crossbar pour partager l'accès à la RAM, on a une bonne machine de tueur =)

/me qui retourne rêver sur un pdf décrivant l'O2.

Oups, c''est vrai que tout mon raisonnement se basait sur le client X générique et non sur un client plus spécifique comme Xgl =)

Conceptuellement parlant OpenGL/GLX est dans X11. Cela signifie qu'il faut déjà un serveur X11 qui tournent pour pouvoir utiliser OpenGL/GLX (Il te faut un display etc...). Donc Xgl doit avoir un serveur X11 derrière!

il n'y a que GLX qui est dans X, OpenGL est indépendant de tous "système de fenêtrage" (après, qu'ATI ou Nvidia fasse des gros hacks qui lient OpenGL à X, c'est leur problèmes, on verra leur rapidité à s'adapter à EGL).

Ceci étant, en parcourant les specs d'EGL, j'ai eu l'impression de lire les specs de GLX, surtout dans la manière de découper une contexte en un état client et un état serveur (ce que fait GLX pour permettre d'encapsuler OpenGL dans le protocole X). Au final, EGL m'apparait comme une API unifiant GLX/WGL/AGL et pouvant reposer sur un système de fenêtrage. Avoir un EGL marchant sur X ou sur le framebuffer de Linux ne changera rien pour le toolkit utilisé (graphiquement parlant).


Le contexte de l'unité 3D (en supposant qu'il n'y a pas une contexte unique pour toute la GPU) n'est pas énorme au point d'atteindre plusieurs Mo : Il y a les piles de matrices de transformations (la plus grande pile doit faire 32 éléments), les états comme le mode de remplissage des polygones (quelques champs de bits) , les sources de lumières (8 grand max), etc. Les textures, shaders et autre VBO sont déjà en VRAM. De plus, des infos sont stockées côté pilotes, pas côté GPU. Comparé à une map de TuxRacer, un contexte doit être insignifiant.

Il faut aussi garder en tête qu'OpenGL est un flux de données et c'est le pilotes qui se charge de le gèrer (pour t'en convaincre regarde l'utilité de glFinish). Si glXMakeCurrent (et son équivalent eglMakeCurrent) doit attendre la fin du traitement d'une autre application 3D, il attendra avant de prendre la main. Le fait que Xgl soit fonctionnel sur un Celeron et un proc graphique i810 montre qu'il n'y a pas trop de soucis à se faire de ce côté là (je garde une réserve car on n'a pas vu de vidéos de Xgl/Compiz avec des oo.org et autres grosses applications, ça se trouve, c'est catastrophique):

Avant on trouvait que le WM/DM se trainait le bit avec un petit proc, il faudra être conscient que la GPU peut en faire de même ...


Rem

Il ne faut pas oublier qu'un processeur graphique est décomposé en (en gros) 3 sous systèmes :
- une unité 2D (exploitée pour le dessin des interfaces anté MacOSX, Xgl, Vista)
- une unité 3D (exploitée par OpenGL ou Direct3D)
- une unité de traitement vidéo (overlay, (dé)compression, etc.)

Si les 2 dernières sont améliorées au fil du temps, la première en revanche ne l'est plus du tout. Il suffit de voir le battage que font Nvidia & consort sur les nouvelles GPU qu'ils sortent tous les 6 mois/1 an, ça ne parle que de vidéo et de 3D. On aura donc beau dire mais les GPU "modernes" savent afficher plus rapidement une simple ligne avec l'unité 3D qu'avec la 2D (et il en est de même pour toutes les primitives 2D).


L'extension que tu décris pour normaliser les "accès bas niveau" existe déjà, c'est le couple OpenGL/GLX. Je ne pense pas d'ailleurs qu'une extension soit le plus efficace (c'est une extension, donc un comportement rajouté). Permettre le choix entre un rendu 2D et un rendu 3D (au sens utilisation de l'unité 2D ou 3D) serait, selon moi, plus pertinent (et j'y vois aussi une facilité lors de la configuration de X:)

Pour pour le backend 2D, on aurait par exemple :
toolkit <-> API de X <-> backend X 2D <-> pilote <-> matériel
et pour le backend 3D :
toolkit <-> API de X <-> backend X 3D <-> OpenGL/GLX <-> pilote <-> matériel

On peut d'ailleurs faire le rapprochement avec le
toolkit <-> API vectoriel <-> backend 3D <-> OpenGL/GLX <-> pilote <-> matériel
qu'ont Gtk+2.8 et Qt4.

Après, j'suis pas dev chez Xorg/Novell/autre, alors mon avis me pèse pas lourd =)

Il est d'ailleurs intéressant de voir que Xgl utilise glitz, on retombe sur le
toolkit <-> API de X <-> "backend 3D" <-> OpenGL/GLX <-> pilote <-> matériel

Peut-être qu'à terme, on verra glitz intégré à X =)


On parle des effets de compositions que permettent la transparence et les textures mais d'autres mécanismes tels que les VBO (Vertex Buffer Object) peuvent apporter d'autres avantages comme réduire l'empreinte d'un programme en mémoire centrale en stockant des informations dans la mémoire graphique. Cela permet ainsi de minimiser l'envoi d'information sur le bus graphique.

Après, on peut se permettre de rêver. Pour la simple page de rédaction que j'utilise actuellement, les éléments statiques tel le bouton "Vérifier" n'auraient plus besoin d'être redessiné entièrement mais juste à donner un ordre comme "desssine le widget XXyyZZ_0324 à telle position". Comparé à "dessine le rectangle plein P1 P2 P3 P4 - dessine le rectangle vide P1 P2 P3 P3 - écrit 'Vérifier' avec tels paramètres", le gain serait énorme.


Pour revenir sur la surcharge de la GPU à cause de l'abus d'effets (que tu évoques dans un post précédent), le problème est autre. Si tu veux jouer à Doom3, tu as une grosse machine, si c'est pour faire du bureautique/web/mp3^Wvorbis, une configuration plus modeste est plus que suffisante. Après, si ça laggue car il y a trop d'effets, c'est le problème de l'utilisateur pas celui des développeurs (enfin si, l'optimisation est de leur ressort mais c'est encore un autre problème;)

D'ailleurs, à ce que j'en ai compris, Xgl n'utilise que :
- des textures pour stocker le contenu des fenêtres (widgets ?)
- des polygones pour faire un support aux textures
- du rendu dans une texture pour manipuler 2D, 3D et vidéo dans un tout cohérent
- la transparence pour aider à l'appréhension du bureau
- des effets de couleur comme la désaturation
- un peu de physique empirique pour les effets sur les fenêtres

Somme toute des trucs implémentés dans les GPU depuis belle lurette (je ne sais plus quelle démo a été faite sur un celeron avec un proc graphique genre i810).

Toutefois, une utilisation des shaders pour améliorer le filtrage d'image (comme les summed area) serait une utilisation saine comparé à afficher tout le texte visible à l'écran avec un effet de bumpmapping /o\


Je ne pense pas que l'utilisation directe d'OpenGL dans une application pour faire des effets soit maline. D'ailleurs, les travaux actuels portent plus sur la vectorisation (et donc aussi la simplification) de l'affichage (Cf Cairo et Arthur pour ne pas les citer). Le but est de ressortir des cartons un concept assez vieux : avoir la même API d'affichage quelque soit le support (écran, imprimante, pdf, image ou que sais-je encore). Un fois ces mécanismes stables et éprouvés, ils pourront se pencher sur la suite (utilisation de shader et de toutes autres joyeusetés futures). Mais pour l'instant, Qt4 n'est pas encore majoritairement utilisé et les backends de Cairo sont en cours de finalisation. Donc attendons de voir avant de prendre peur ;)

les 2¢ d'un réinventeur de roue chevronné /o\

Ce n'est pas "Baldur's Gates" mais "Neverwinter Nights" .... rha flute ! "Bill Gates" :]

Tu peux essayer avec une manivelle mais ça peut vite devenir chiant :))

donc en comptant bien, ça fait les 2 TVs, le magnétoscope, le lecteur de DVD, les décodeurs TNT, cable et satellite, pour la chaîne audio, y'a l'ampli et la platine CD. Avec les 3 prises, ça fait .... 12 télécommandes ... tu as une corbeille pour toutes les mettre ou tu as une universelle ? :]

ha ! il me faut sortir ? pas de problème /o\

pour les citations, il y avait eu un sympatique Thema sur le brevetage du vivants sur Arte (y'a 3 semaines, 1 mois) dont voici un petit résumé :

1er reportage :

Le haricot jaune. Un américain en voyage au Mexique, ramène chez lui des plants de haricot jaune et entreprend de le cultiver. Il le brevète histoire de se protéger. C'est bête, le Mexique fait partie de la zone géographique où les brevets américains sont valides ; les paysans mexicains doivent donc payer des royalties au sympatique américain qui prétend être dans son bon droit. La procédure pour casser le brevet est toujours en cours. Faut juste savoir que ce haricot (comme la quasi totalité des autres variétés de haricot) est originaire du Mexique et qu'il y est cultivé depuis plusieurs milliers d'année.

Le margousier indien. Cet arbre fait partie de la pharmacopée indienne depuis plusieurs millénaires. Un laboratoire américain a breveté le procédé d'extraction *et* le principe actif. Je ne sais plus s'il a fallu 10 ou 15 ans pour casser le brevet.

La céréale anti-round'up (faite par Monsanto justement) au Canada. Je ne souviens plus trop de cette partie là mais par la simple contamination de leurs champs, les agriculteurs devaient payer des royalties à Monsanto.

2nd reportage : l'histoire du blé.

Dans la plupart des pays, les variétés de blé commercialisables doivent respecter une "chartre" (je ne me souviens plus du terme exact) et aucunes variétés des blés endémiques ne la respectent. Le seul blé utilisable vient donc des semenciers (qui a parlé de position dominante ?).

Une fondation américaine a cherché à produire des blés pour nourrir le tiers monde. Elle a donc produit un nombre très restreint de variété (pour ne pas dire une seule) que l'on peut cultiver sous tous les climats/lattitude/etc. Elle a fait machine arrière depuis une bonne décennie et cherche à réintroduire les espèces de blé propres à chaque région du globe car elle s'est rendue compte que son action avait été plus néfaste que bénéfique.

Monsanto (encore !?) rachète des semenciers en Inde pour écouler les blés qu'elle n'arrive plus à vendre en "occident".

mes 2¢ =)

Trop gros, 'passeront pas (oui, oui, j'utilise bien le pluriel:).

héhé ... pas assez rapide =)

Art. 1er. - L'état d'urgence peut être déclaré sur tout ou partie du territoire métropolitain, de l'Algérie ou des départements d'outre-mer ...

Ça la fout mal d'avoir encore des textes imprégnés de colonialisme :'-(

peut être que la réponse est dans la question : *co*processeur ;)