Ca ne fonctionne pas chez moi sous Mozilla 1.5. Je leur avait envoyé un mail à ce propos mais je n'ai jamais eu de réponse. De ce que je me rappelle, c'était juste un petit bug du à l'utilisation de code spécifique à IE.
C'est vrai que pour la classification, il y a des gros progrès à faire. Il faudrait avoir la possibilité de classer un fichier dès qu'on veut le sauver sur disque, à partir de n'importe quelle appli. Tiens, je crois que je vais faire des petites recherches sur WinFS et Longhorn...
> En tant qu'utilisateur je veux effectuer une action. L'outil importe peu. Si je veux voir
> une image, je me fout pas mal que ce soit avec gqview, kview, eye of gnome.
Il arrive que certains programmes soient plus adaptés que d'autres selon le contexte. La fonction de visualisation d'image est assez vague, elle peut supposer des tas de sous-fonctions qu'il serait trop lourd de définir par des noms d'actions explicites, mais que l'utilisateur peut intégrer implicitement en choisissant lui-même l'application. Ex: voir une image unique, voir plusieurs images dans une même fenêtre, afficher un diaporama d'images, etc.
D'autres part, certaines fonctionnalités sont mieux supportées par certaines applications que d'autres et vice-versa. Dans le cas de la visualisation d'images, on pourrait citer la qualité du support des différents formats de fichiers, la possibilité de voir des images animées, transparentes, etc.
> On a déjà un système connu et parfaitement fonctionnel qui fait ça : Les menus
> contextuels. Fichier son -> Clic droit -> Ecouter.
L'intérêt du système présenté c'est que si on a envie d'écouter de la musique, on n'est pas obligé d'aller la chercher dans le(s) bon(s) répertoire(s) avec un gestionnaire de fichiers. On clique juste sur la fonction de lecture et la liste des fichiers est automatiquement restreinte aux seuls fichiers musicaux, où qu'ils se trouvent sur le disque. Ensuite, on peut lancer la lecture sur l'ensemble des fichiers, en sélectionner seulement quelques-uns ou limiter la liste selon certains critères. Voir "Using segusoLand as a catalog: organizing information" qui montre comment ne retenir que les meilleures chansons de Tracy Chapman par exemple.
> Enfin c'est bien joli ce truc mais comment fait on avec un grand nombre de fichiers?
> Le concept de répertoire semble un peu mis de coté.
Non, il est présent, mais en plus puissant parce que multi-critères et pas arborescent. Il faut avoir classé ses fichiers en cliquant sur Options | Directories, puis il suffit de cliquer sur Change view. C'est illustré dans l'exemple précédent où on combine "Tracy Chapman" et "Very good".
Bref, je trouve le principe de ce programme plutôt sympa, ça me paraît pas mal adapté aux personnes qui découvrent un système et ne connaissent pas les applications disponibles dessus. Et puis ça permet de s'affranchir du principe de classification arborescente que je trouve assez limité par rapport à une classification multi-critères.
C'est un jeu sympa où chaque joueur dirige un petit lapin et essaye d'écraser les autres lapins en évitant de se faire écraser lui-même. C'est plutôt marrant et mignon tout plein, je pense que c'est assez adapté aux jeunes enfants (seulement 3 touches à utiliser). Mais il ne faut pas oublier d'utiliser l'option -nogore dans ce cas. Ca fonctionne en réseau, mais ça peut se jouer jusqu'à 4 sur la même machine.
> Effectivement Alien Flux n'est pas Prince of persia je te l'accorde, mais le jeu est
> vraiment très prenant et prouve que techniquement c'est possible.
Quand un équivalent de Prince of Persia tournera en Java, j'applaudirais des deux mains. Mais on n'en est pas encore là et rien ne me dit pour l'instant que c'est techniquement possible. Bon, tu vas me répondre que rien ne dit le contraire non plus... :)
En attendant ça m'aura au moins donné envie d'essayer gcj/lwjgl. Je suis curieux de voir ce que ça donne comparé à mon code C/AllegroGL sur ma petite config.
> Non, ce n'est pas contradictoire. Le fait que la prise en main soit simple ne
> t'affranchit pas d'avoir du fait de posséder un minimum de compétences pour optimiser.
Dans ce cas Java n'a pas d'avantage par rapport à C++ sur ce plan ? C++ est plus compliqué à prendre en main, certes, mais il n'y a pas besoin de faire d'efforts particuliers pour optimiser son code.
> Euh, t'es sûr ? Le programme CAP qui donnait accès sous NDA à des build hebdo
C'est à ça que je faisais référence, je savais pas que c'était arrêté, désolé...
> En premier comparer Alien Flux à Asteroid, c'est vraiment n'importe quoi et traiter les
> codeurs d'amateurs c'est encore pire !!!
Ce que je voulais dire par là, c'est qu'un shareware ne rentre pas dans la catégorie des jeux professionnels selon moi, mais dans celle des jeux amateurs. Le mot amateur n'a rien de péjoratif, je ne critique pas le jeu en temps que tel, il est sûrement très sympa. Mais un shoot them'up est très loin techniquement de ce qui se fait de mieux à l'heure actuelle et ça ne m'étonne pas qu'un jeu de ce type tourne correctement en Java. J'attends encore de voir un jeu commercial écrit en Java. Ca viendra peut-être, mais on n'y est pas encore.
> Enfin, sache que Java n'est plus un argument differentiateur au niveau comercial. En
> premier, c'est une techno largement maitrisée qui ne demande pas vraiment d'expert
> pour être prise en main,
> Je n'ai jamais dit que c'etait simple à faire, et que Java etait un miracle. Mais un
> developpeur soucieux d'optimiser son code peut le faire ;-)
D'un côté tu me dis que Java est simple à prendre en main et qu'il ne faut pas être expert pour l'utiliser, de l'autre tu me dis que ce n'est pas simple d'optimiser du code Java, tu ne sens pas comme une contradiction là ?
> Je t'invite à tester d'ici qqe semaines la version beta du JDK 1.5 pour découvrir tout
> ça ...
Pas besoin d'attendre quelques semaines, il est déjà possible d'avoir accès aux early builds. Bon, il faut signer un NDA et c'est que de l'alpha pour l'instant, mais ça peut donner une idée...
Pour reprendre ton titre, non, je ne pense vraiment pas avoir raté d'épisode, je programme depuis 18 ans et je connais *un peu* le domaine.
> Par contre dire en brut "Java trop lent" c'est retardé de 4ans de façon trolesque!
Je ne dis pas que Java est trop lent dans l'absolu, la "lenteur" est quelque chose de relatif à mettre en relation avec les besoins réels d'une application. Je pense que dans le cadre des jeux vidéos ou des applications graphiques client lourdes, Java n'est pas adapté. D'ailleurs on ne le voit pas/peu dans ce cadre là.
> je passerai sur les plusieurs millions de midlet vendues par les telco depuis 6mois
Oui, mieux vaut passer là-dessus, quand on connaît un peu le domaine on sait que les "vrais" jeux commerciaux pour mobiles sont écrits en natif. Pour les autres types d'applications sur mobiles, oui, Java a peut-être sa place.
> un exemple de jeu "plus digne de ce nom": le tout dernier sortit et mon préféré Alien Flux.
Je te parlais de jeux commerciaux, toi tu me sors un exemple de jeu amateur, clône d'Asteroids qui tournait en salles d'arcades il y a 20 ans. Soyons sérieux...
> Et si des meneurs du monde opensource comme la fondation Apache n'hesite plus à
> s'investir dedans [...] c'est qu'ils ont comprit que tel est l'interret du monde libre.
Tu mets le doigt exactement sur ce que je voulais dire. Java côté serveur, ok, côté client, il faut voir dans quel cadre. En tout cas, pas celui des jeux vidéos ni celui des applications graphiques lourdes.
> Pour finir, je te rassure le temps viendra aussi ou Java sera rendu obsolète par une
> nouvelle génération de concepts.
Pourquoi veux tu que Java soit rendu obsolète ? Est-ce qu'un langage devient obsolète parce qu'il existe des concepts nouveaux ? Non bien sûr. C++ n'est pas devenu obsolète parce que Sun a sorti l'idée d'une machine virtuelle et a supprimé les pointeurs. Les langages s'adaptent aux nouvelles idées, y compris Java qui reprend les generics de C++ dans la prochaine mouture.
> Mais en attendant, il est une oportunité à saisir pour tous, et est maintenant la
> référence du milieu.
La référence de quel milieu ? Pour les jeux vidéos et les applications graphiques lourdes, c'est le C++ la référence et l'assembleur par moments. Java est un outil parmi d'autres, comme la 50aine de langages qui existent. A t'entendre on croirait que le Messie est arrivé et qu'on peut jeter aux orties tout ce qu'il y avait avant. Non, on choisit le langage ou l'outil le plus adapté pour un problème donné, point.
> Rien en informatique n'est définitif, mais on ne revient jamais en arrière, crois moi.
Qu'est ce que ça peut m'énerver ces petites phrases de donneurs de leçon. J'espère que t'as au moins 50 balais pour parler comme ça...
Je ne dis pas que les wrappers OpenGL pour Java sont lents, ce serait stupide puisqu'ils appelent directement des fonctions OpenGL. A part l'overhead dans l'appel, je vois pas ce qui pourrait les ralentir.
Un application OpenGL ne se résume pas à du rendu graphique, derrière il y a des traitements sinon ce n'est qu'une démo. Et c'est dans ce cadre que je trouve que Java n'est pas adapté car trop lent et trop gourmand. Dans le lien que je donnais, j'ai constaté qu'un Quake 1 OpenGL est 14 fois moins rapide en Java qu'en C. Et c'est à mon avis la raison pour laquelle il n'y à l'heure actuelle aucun jeu commercial écrit en Java.
Cela dit, j'ai rien contre Java comme langage, je l'utilise dans mon boulot et je le trouve même plutôt sympa, mais je ne vois simplement pas l'intérêt de l'utiliser dans ce type d'application.
> Oui, mais il s'agit surement de la version en rendu software
Non, il ne s'agit évidemment pas de la version en rendu software, les deux versions fonctionnaient en OpenGL, sinon je ne vois pas vraiment l'intérêt de la comparaison.
> par contre, tjrs selon carmack, avec la version opengl, on pouvait tout refaire en C,
> le gros étant fait par la carte
Non, le gros du jeu n'est pas fait par la carte. La carte graphique ne gère que le graphisme, un jeu c'est beaucoup plus que ça : IA, physique, détection de collisions, etc. C'est exactement ce que montre la comparaison dont je donnais le lien. Et d'ailleurs, un bon programmeur de jeux fera en sorte de balancer équitablement la charge sur le CPU et le GPU pour profiter au maximum des capacités de la machine.
Ce que dit Carmack c'est que en rendu software, c'est le graphisme qui prend tout le temps machine et c'est pour ça qu'il est écrit en assembleur, ce n'est plus le cas en rendu hardware évidemment.
Bref, à rendu graphique égal, Quake en Java est 14 fois moins rapide que Quake en C sur ma machine.
> on ne peut pas distribuer les firmwares necessaires donc on ne supporte pas les modems eci.
Dans la version non-libre vous redistribuez les drivers Nvidia grâce à la clause "Linux Exception" de leur licence. Vous ne pouvez pas obtenir un accord du même type avec ECI ? Ca semble quand même être dans leur intérêt que leurs modems fonctionnent sur le maximum de plates-formes.
> il y a une petition sur le site du driver pour faire pression sur eci pour que les
> firmwares et les fichiers de synchro soient redistribuables
Sur la page du driver concernant la pétition, il n'est question que de l'accès aux spécifications, rien concernant la redistribution du firmware. Sinon, ça me paraît étonnant que les fichiers de synchro ne soient pas redistribuables, ils sont en libre téléchargement sur le site du driver et ils semblent avoir été faits par des utilisateurs.
> Tu vas dire que je suis de mauvaise foi, mais je ne vois pas pourquoi Ant aurait à se
> soucier de ce genre de problématique. Personne n'a jamais dit que Ant était un
> compilateur, je crois ?
man make
Et accessoirement, essaye de lire quelques bouquins et documentations sur la programmation, ça t'évitera de raconter n'importe quoi.
S'il n'y a pas d'exploit connu pour une faille donnée, l'utilisateur qui n'aura pas appliqué de correctif ne se rendra compte de rien...
C'est peut-être aussi le nombre d'exploits rapportés au nombre de failles qui fait la différence dans l'impression de sécurité que donnent les deux systèmes.
Donc le code de Ryzom peut ne pas être sous GPL à condition que Nevrax utilise NeL sous une autre licence que la GPL. Et dans ce cas, les patches extérieurs ne pourront être intégrés dans cette version de NeL que si leurs auteurs cèdent leurs droits à Nevrax.
Merci, c'est plus clair maintenant.
Mais du coup, je sais toujours pas si Ryzom sera GPL... :)
[^] # Re: Voyages SNCF dot com accroit sa compatibilité
Posté par Frédéric Lopez . En réponse au journal Voyages SNCF dot com accroit sa compatibilité. Évalué à 1.
Ca ne fonctionne pas chez moi sous Mozilla 1.5. Je leur avait envoyé un mail à ce propos mais je n'ai jamais eu de réponse. De ce que je me rappelle, c'était juste un petit bug du à l'utilisation de code spécifique à IE.
[^] # Re: Une nouvelle approche dans le monde des GUI
Posté par Frédéric Lopez . En réponse à la dépêche Une nouvelle approche dans le monde des GUI. Évalué à 1.
[^] # Re: Sortie de Monkey Bubble 0.1.8
Posté par Frédéric Lopez . En réponse à la dépêche Sortie de Monkey Bubble 0.1.8. Évalué à 2.
http://www.cubeengine.com/(...)
[^] # Re: Une nouvelle approche dans le monde des GUI
Posté par Frédéric Lopez . En réponse à la dépêche Une nouvelle approche dans le monde des GUI. Évalué à 1.
[^] # Re: Une nouvelle approche dans le monde des GUI
Posté par Frédéric Lopez . En réponse à la dépêche Une nouvelle approche dans le monde des GUI. Évalué à 3.
> une image, je me fout pas mal que ce soit avec gqview, kview, eye of gnome.
Il arrive que certains programmes soient plus adaptés que d'autres selon le contexte. La fonction de visualisation d'image est assez vague, elle peut supposer des tas de sous-fonctions qu'il serait trop lourd de définir par des noms d'actions explicites, mais que l'utilisateur peut intégrer implicitement en choisissant lui-même l'application. Ex: voir une image unique, voir plusieurs images dans une même fenêtre, afficher un diaporama d'images, etc.
D'autres part, certaines fonctionnalités sont mieux supportées par certaines applications que d'autres et vice-versa. Dans le cas de la visualisation d'images, on pourrait citer la qualité du support des différents formats de fichiers, la possibilité de voir des images animées, transparentes, etc.
> On a déjà un système connu et parfaitement fonctionnel qui fait ça : Les menus
> contextuels. Fichier son -> Clic droit -> Ecouter.
L'intérêt du système présenté c'est que si on a envie d'écouter de la musique, on n'est pas obligé d'aller la chercher dans le(s) bon(s) répertoire(s) avec un gestionnaire de fichiers. On clique juste sur la fonction de lecture et la liste des fichiers est automatiquement restreinte aux seuls fichiers musicaux, où qu'ils se trouvent sur le disque. Ensuite, on peut lancer la lecture sur l'ensemble des fichiers, en sélectionner seulement quelques-uns ou limiter la liste selon certains critères. Voir "Using segusoLand as a catalog: organizing information" qui montre comment ne retenir que les meilleures chansons de Tracy Chapman par exemple.
> Enfin c'est bien joli ce truc mais comment fait on avec un grand nombre de fichiers?
> Le concept de répertoire semble un peu mis de coté.
Non, il est présent, mais en plus puissant parce que multi-critères et pas arborescent. Il faut avoir classé ses fichiers en cliquant sur Options | Directories, puis il suffit de cliquer sur Change view. C'est illustré dans l'exemple précédent où on combine "Tracy Chapman" et "Very good".
Bref, je trouve le principe de ce programme plutôt sympa, ça me paraît pas mal adapté aux personnes qui découvrent un système et ne connaissent pas les applications disponibles dessus. Et puis ça permet de s'affranchir du principe de classification arborescente que je trouve assez limité par rapport à une classification multi-critères.
[^] # Re: Une nouvelle approche dans le monde des GUI
Posté par Frédéric Lopez . En réponse à la dépêche Une nouvelle approche dans le monde des GUI. Évalué à 5.
apt-get install libboost-dev
apt-get install swi-prolog
apt-get install libgtkmm2.0-1c102
apt-get install libgtkmm2.0-dev
apt-get install libncurses-dev
src/Makefile :
all: segusoLand.cc
g++ -o segusoLand.exe segusoLand.cc `pkg-config gtkmm-2.0 --cflags --libs` -I/usr/lib/swi-prolog/include/ -lplmt -lpthread -lcurses -L/usr/lib/swi-prolog/runtime/i386/
cd src
make
export SWI_HOME_DIR=/usr/lib/swi-prolog/
./segusoLand.exe
# Re: Initiation à GNU/Linux au Burkina Faso
Posté par Frédéric Lopez . En réponse à la dépêche Initiation à GNU/Linux au Burkina Faso. Évalué à 2.
[^] # Re: Il y a 10 ans TILT fesait TILT
Posté par Frédéric Lopez . En réponse au journal Il y a 10 ans TILT fesait TILT. Évalué à 2.
Merci pour le lien en tout cas, très cool...
# Re: ToolBox -> Linux
Posté par Frédéric Lopez . En réponse au journal ToolBox -> Linux. Évalué à 1.
DrawSWF
http://drawswf.sourceforge.net/(...)
mvComicsMaker
http://mvcm.sourceforge.net/(...)
Moho (non libre, non gratuit)
http://www.lostmarble.com/index.shtml(...)
# Re: Cherche jeux en reseau pour jeunes enfants
Posté par Frédéric Lopez . En réponse au journal Cherche jeux en reseau pour jeunes enfants. Évalué à 1.
http://jumpbump.mine.nu/(...)
C'est un jeu sympa où chaque joueur dirige un petit lapin et essaye d'écraser les autres lapins en évitant de se faire écraser lui-même. C'est plutôt marrant et mignon tout plein, je pense que c'est assez adapté aux jeunes enfants (seulement 3 touches à utiliser). Mais il ne faut pas oublier d'utiliser l'option -nogore dans ce cas. Ca fonctionne en réseau, mais ça peut se jouer jusqu'à 4 sur la même machine.
[^] # Re: c pas gentil <:o)
Posté par Frédéric Lopez . En réponse à la dépêche Looking Glass - Desktop 3D. Évalué à 1.
> vraiment très prenant et prouve que techniquement c'est possible.
Quand un équivalent de Prince of Persia tournera en Java, j'applaudirais des deux mains. Mais on n'en est pas encore là et rien ne me dit pour l'instant que c'est techniquement possible. Bon, tu vas me répondre que rien ne dit le contraire non plus... :)
En attendant ça m'aura au moins donné envie d'essayer gcj/lwjgl. Je suis curieux de voir ce que ça donne comparé à mon code C/AllegroGL sur ma petite config.
> Non, ce n'est pas contradictoire. Le fait que la prise en main soit simple ne
> t'affranchit pas d'avoir du fait de posséder un minimum de compétences pour optimiser.
Dans ce cas Java n'a pas d'avantage par rapport à C++ sur ce plan ? C++ est plus compliqué à prendre en main, certes, mais il n'y a pas besoin de faire d'efforts particuliers pour optimiser son code.
> Euh, t'es sûr ? Le programme CAP qui donnait accès sous NDA à des build hebdo
C'est à ça que je faisais référence, je savais pas que c'était arrêté, désolé...
[^] # Re: c pas gentil <:o)
Posté par Frédéric Lopez . En réponse à la dépêche Looking Glass - Desktop 3D. Évalué à 1.
> codeurs d'amateurs c'est encore pire !!!
Ce que je voulais dire par là, c'est qu'un shareware ne rentre pas dans la catégorie des jeux professionnels selon moi, mais dans celle des jeux amateurs. Le mot amateur n'a rien de péjoratif, je ne critique pas le jeu en temps que tel, il est sûrement très sympa. Mais un shoot them'up est très loin techniquement de ce qui se fait de mieux à l'heure actuelle et ça ne m'étonne pas qu'un jeu de ce type tourne correctement en Java. J'attends encore de voir un jeu commercial écrit en Java. Ca viendra peut-être, mais on n'y est pas encore.
> Enfin, sache que Java n'est plus un argument differentiateur au niveau comercial. En
> premier, c'est une techno largement maitrisée qui ne demande pas vraiment d'expert
> pour être prise en main,
> Je n'ai jamais dit que c'etait simple à faire, et que Java etait un miracle. Mais un
> developpeur soucieux d'optimiser son code peut le faire ;-)
D'un côté tu me dis que Java est simple à prendre en main et qu'il ne faut pas être expert pour l'utiliser, de l'autre tu me dis que ce n'est pas simple d'optimiser du code Java, tu ne sens pas comme une contradiction là ?
> Je t'invite à tester d'ici qqe semaines la version beta du JDK 1.5 pour découvrir tout
> ça ...
Pas besoin d'attendre quelques semaines, il est déjà possible d'avoir accès aux early builds. Bon, il faut signer un NDA et c'est que de l'alpha pour l'instant, mais ça peut donner une idée...
[^] # Re: Tu as du raté un épisode ... (le IIIe ?)
Posté par Frédéric Lopez . En réponse à la dépêche Looking Glass - Desktop 3D. Évalué à 0.
> Par contre dire en brut "Java trop lent" c'est retardé de 4ans de façon trolesque!
Je ne dis pas que Java est trop lent dans l'absolu, la "lenteur" est quelque chose de relatif à mettre en relation avec les besoins réels d'une application. Je pense que dans le cadre des jeux vidéos ou des applications graphiques client lourdes, Java n'est pas adapté. D'ailleurs on ne le voit pas/peu dans ce cadre là.
> je passerai sur les plusieurs millions de midlet vendues par les telco depuis 6mois
Oui, mieux vaut passer là-dessus, quand on connaît un peu le domaine on sait que les "vrais" jeux commerciaux pour mobiles sont écrits en natif. Pour les autres types d'applications sur mobiles, oui, Java a peut-être sa place.
> un exemple de jeu "plus digne de ce nom": le tout dernier sortit et mon préféré Alien Flux.
Je te parlais de jeux commerciaux, toi tu me sors un exemple de jeu amateur, clône d'Asteroids qui tournait en salles d'arcades il y a 20 ans. Soyons sérieux...
> Et si des meneurs du monde opensource comme la fondation Apache n'hesite plus à
> s'investir dedans [...] c'est qu'ils ont comprit que tel est l'interret du monde libre.
Tu mets le doigt exactement sur ce que je voulais dire. Java côté serveur, ok, côté client, il faut voir dans quel cadre. En tout cas, pas celui des jeux vidéos ni celui des applications graphiques lourdes.
> Pour finir, je te rassure le temps viendra aussi ou Java sera rendu obsolète par une
> nouvelle génération de concepts.
Pourquoi veux tu que Java soit rendu obsolète ? Est-ce qu'un langage devient obsolète parce qu'il existe des concepts nouveaux ? Non bien sûr. C++ n'est pas devenu obsolète parce que Sun a sorti l'idée d'une machine virtuelle et a supprimé les pointeurs. Les langages s'adaptent aux nouvelles idées, y compris Java qui reprend les generics de C++ dans la prochaine mouture.
> Mais en attendant, il est une oportunité à saisir pour tous, et est maintenant la
> référence du milieu.
La référence de quel milieu ? Pour les jeux vidéos et les applications graphiques lourdes, c'est le C++ la référence et l'assembleur par moments. Java est un outil parmi d'autres, comme la 50aine de langages qui existent. A t'entendre on croirait que le Messie est arrivé et qu'on peut jeter aux orties tout ce qu'il y avait avant. Non, on choisit le langage ou l'outil le plus adapté pour un problème donné, point.
> Rien en informatique n'est définitif, mais on ne revient jamais en arrière, crois moi.
Qu'est ce que ça peut m'énerver ces petites phrases de donneurs de leçon. J'espère que t'as au moins 50 balais pour parler comme ça...
[^] # Re: Looking Glass - Desktop 3D
Posté par Frédéric Lopez . En réponse à la dépêche Looking Glass - Desktop 3D. Évalué à 1.
Un application OpenGL ne se résume pas à du rendu graphique, derrière il y a des traitements sinon ce n'est qu'une démo. Et c'est dans ce cadre que je trouve que Java n'est pas adapté car trop lent et trop gourmand. Dans le lien que je donnais, j'ai constaté qu'un Quake 1 OpenGL est 14 fois moins rapide en Java qu'en C. Et c'est à mon avis la raison pour laquelle il n'y à l'heure actuelle aucun jeu commercial écrit en Java.
Cela dit, j'ai rien contre Java comme langage, je l'utilise dans mon boulot et je le trouve même plutôt sympa, mais je ne vois simplement pas l'intérêt de l'utiliser dans ce type d'application.
[^] # Re: Looking Glass - Desktop 3D
Posté par Frédéric Lopez . En réponse à la dépêche Looking Glass - Desktop 3D. Évalué à 0.
Non, il ne s'agit évidemment pas de la version en rendu software, les deux versions fonctionnaient en OpenGL, sinon je ne vois pas vraiment l'intérêt de la comparaison.
> par contre, tjrs selon carmack, avec la version opengl, on pouvait tout refaire en C,
> le gros étant fait par la carte
Non, le gros du jeu n'est pas fait par la carte. La carte graphique ne gère que le graphisme, un jeu c'est beaucoup plus que ça : IA, physique, détection de collisions, etc. C'est exactement ce que montre la comparaison dont je donnais le lien. Et d'ailleurs, un bon programmeur de jeux fera en sorte de balancer équitablement la charge sur le CPU et le GPU pour profiter au maximum des capacités de la machine.
Ce que dit Carmack c'est que en rendu software, c'est le graphisme qui prend tout le temps machine et c'est pour ça qu'il est écrit en assembleur, ce n'est plus le cas en rendu hardware évidemment.
Bref, à rendu graphique égal, Quake en Java est 14 fois moins rapide que Quake en C sur ma machine.
[^] # Re: Looking Glass - Desktop 3D
Posté par Frédéric Lopez . En réponse à la dépêche Looking Glass - Desktop 3D. Évalué à 0.
http://linuxfr.org/comments/221474.html(...)
[^] # Re: Looking Glass - Desktop 3D
Posté par Frédéric Lopez . En réponse à la dépêche Looking Glass - Desktop 3D. Évalué à 0.
http://linuxfr.org/comments/221474.html(...)
[^] # Re: Bougez avec MandrakeMove !
Posté par Frédéric Lopez . En réponse à la dépêche Bougez avec MandrakeMove !. Évalué à 2.
Dans la version non-libre vous redistribuez les drivers Nvidia grâce à la clause "Linux Exception" de leur licence. Vous ne pouvez pas obtenir un accord du même type avec ECI ? Ca semble quand même être dans leur intérêt que leurs modems fonctionnent sur le maximum de plates-formes.
> il y a une petition sur le site du driver pour faire pression sur eci pour que les
> firmwares et les fichiers de synchro soient redistribuables
Sur la page du driver concernant la pétition, il n'est question que de l'accès aux spécifications, rien concernant la redistribution du firmware. Sinon, ça me paraît étonnant que les fichiers de synchro ne soient pas redistribuables, ils sont en libre téléchargement sur le site du driver et ils semblent avoir été faits par des utilisateurs.
[^] # Re: Bougez avec MandrakeMove !
Posté par Frédéric Lopez . En réponse à la dépêche Bougez avec MandrakeMove !. Évalué à 2.
[^] # Re: Dernières nouveautés J2EE
Posté par Frédéric Lopez . En réponse à la dépêche Dernières nouveautés J2EE. Évalué à -1.
> soucier de ce genre de problématique. Personne n'a jamais dit que Ant était un
> compilateur, je crois ?
man make
Et accessoirement, essaye de lire quelques bouquins et documentations sur la programmation, ça t'évitera de raconter n'importe quoi.
[^] # Re: SqueakParty à Paris
Posté par Frédéric Lopez . En réponse à la dépêche SqueakParty à Paris. Évalué à 4.
[^] # Re: WEBMESTRES : vous pouvez bien mieux le faire sous Linux !
Posté par Frédéric Lopez . En réponse à la dépêche Webmestres : vous pouvez aussi le faire sous Linux. Évalué à 1.
http://www.ndeepak.info/stuff/vtu/ginf/index.php(...)
[^] # Re: Les développeurs Windows jugent Linux plus sûr !
Posté par Frédéric Lopez . En réponse à la dépêche Les développeurs Windows jugent Linux plus sûr !. Évalué à 1.
C'est peut-être aussi le nombre d'exploits rapportés au nombre de failles qui fait la différence dans l'impression de sécurité que donnent les deux systèmes.
[^] # Re: Une boîte coule, du code et du contenu se libèrent
Posté par Frédéric Lopez . En réponse à la dépêche Une boîte coule, du code et du contenu se libèrent. Évalué à 1.
Donc le code de Ryzom peut ne pas être sous GPL à condition que Nevrax utilise NeL sous une autre licence que la GPL. Et dans ce cas, les patches extérieurs ne pourront être intégrés dans cette version de NeL que si leurs auteurs cèdent leurs droits à Nevrax.
Merci, c'est plus clair maintenant.
Mais du coup, je sais toujours pas si Ryzom sera GPL... :)
[^] # Re: Une boîte coule, du code et du contenu se libèrent
Posté par Frédéric Lopez . En réponse à la dépêche Une boîte coule, du code et du contenu se libèrent. Évalué à 1.
Si le moteur (NeL) est GPL, le _code source_ du jeu ne devrait-il pas être en GPL ?