Pour grenouille, tu peux faire un ping lo et tu vas te rendre compte que free c'est super rapide.
64 octets from 127.0.0.1: icmp_seq=1 ttl=64 time=0.1 ms
Dis, je comprends pas là. Si tu as "64 octets from 127.0.0.1", ça veut dire que tu pinges ta loopback, tu ne passes pas l'interface réseau et encore moins par la connexion ADSL. Qu'est-ce que tu cherches à prouver ? Si tu as des pertes de paquets en local pur, c'est ton système qui foire, pas Free...
(Disclaimer : je ne suis pas chez Free, je m'en balance, Nerim me convient très bien ;-)))
Tu as dumpé la requête exacte envoyée par le proxy ?
Primordial : vérifie que la séquence à la fin des lignes envoyées par le proxy est bien \r\n (et non \n ou \r ou... certains serveurs sont tolérants mais d'autres non).
Fais un telnet en recopiant directement la requête envoyée par le proxy.
Vérifie que le champ Host est correctement renseigné.
Essaie de changer le User-Agent.
Essaie d'ajouter un Referer.
A mon avis, ils sont amortis depuis longtemps... Du reste, ta ligne téléphonique te permet d'appeler les services d'urgence, ce qui je crois est une obligation du service universel : FT est donc obligé de te fournir ce service, donc de maintenir la connexion de ta ligne au central.
Non. Mais avec l'arrivée de la concurrence en 98 FT a largement baissé ses prix en continuant à faire des bénéfs.
Quels prix ? Certainement pas l'abonnement téléphonique, qui a constamment augmenté (quand j'étais gosse, c'était 20 balles par mois avec un téléphone inclus en location...).
Or je ne souhaite pas cette abonnement, je n'utilise pas mon téléphone fixe.
La hausse de l'abonnement est précisément motivée par la volonté de compenser les baisses de tarifs des communications téléphoniques, obligatoires pour faire face à la concurrence. Tu te trompes de cible...
payer pour quelque chose qu'on ne demande pas et qu'on utilise pas
La ligne téléphonique, tu l'utilises, banane ;) Elle coûte aussi cher à entretenir si tu fais de l'ADSL que si tu l'utilises pour des communications vocales analogiques !
J'oubliais une quatrième possibilité : FT a chaud au c* maintenant qu'EDF commence à s'intéresser sérieusement au haut-débit par la prise électrique (EDF = quasi-100% de couverture et sûrement beaucoup de fibres sous-utilisées).
Tu ne vois pas la différence avec SDL qui propose une api pour les jeux, avec gestion des sprites, etc ?
Non, je ne vois pas la différence, puisque conceptuellement il n'y en a aucune.
Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Donc tu es train de me dire que si la bibliothèque utilisée est mal programmée, les performances du langage qui appellent la bibliothèque sont plus importantes que si la bibliothèque est bien écrite (en toute logique, c'est l'inverse puisqu'il y a moins d'overhead) ? Tu n'as pas l'impression de raconter n'importe quoi ?
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie. Heureusement que tu finis tous tes messages en disant que tes interlocuteurs sont de mauvaise foi :-)
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame
C'est marrant : pour une fois que je ne dis pas cela, tu te mets en tête de le réfuter. C'est une obsession chez toi ?
Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Mais tu es vraiment crétin, c'est ça ?
Je ne veux pas t'imiter dans l'insulte, mais j'impression que c'est toi qui est trop crétin pour comprendre que :
- je suis d'accord depuis le début que les primitives graphiques sont codées en natif
- c'est précisément l'argument que j'employais pour dire que le "rendu complexe" (je rigole doucement) d'Arkanae ne prouvait rien quant aux performances de Java
l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage)
C'est supposément un mémo interne Sun Microsystems. Voici un passage qui concerne l'occupation mémoire de Java (les chiffres sont crédibles et restent à peu près valables à mon avis) :
« Given this data, it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
Further examples of what is possible include the compiling OO languages Eiffel and Sather which fit their garbage collector, exception processor and other infrastructure into roughly 400K of resident set. While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%. »
Les performances des compilateurs C ont augmenté ?
Rassure-moi : tu en doutes sérieusement ? Rien qu'entre gcc 2.9x et gcc 3.0, elles ont fait un bond très sensible, et mesuré. De plus le x86 est un processeur peu sympa pour les compilos (jeu d'instructions foisonnant et peu orthogonal, très peu de registres, règles d'optimisation variables d'un processeur à l'autre et parfois délirantes (pipelines U et V du Pentium...)), ce qui fait qu'il y a eu beaucoup de marge pour l'optimisation du code généré. Cf. pgcc (le gcc optimisé Pentium), egcs (forké de gcc à l'époque où celui-ci stagnait en performances)...
Quake III est programmé en C.
Quake 3, étant sorti il y a quatre ans a été commencé il y a encore plus longtemps, et comme il s'agit d'une suite il est probable qu'ils n'aient pas voulu tout remettre à plat. En tout cas à l'époque où Quake 3 était sorti, certains studios travaillaient déjà en C++, et les compilateurs produisaient déjà du code de bonne qualité (en tout cas celui de Visual Studio).
quand le projet gnome a débuté, l'argument principal était que le C++ [...]
Que viennent faire ici les prétextes peu crédibles du projet Gnome ? Tout le monde sait que Gnome a été créé 1) à cause de la licence de Qt à l'époque 2) parce que RMS et MDI voulaient leur propre desktop (syndrome Not Invented Here + ego surgonflé des deux Messieurs).
mais avec le fait que les jeux open source sont ou bien moches ou bien avec des dessins très mignons (comme frozen bubble), mais très en retard sur les jeux actuels
Oui. Et je te réponds que les "jeux actuels" ne sont pas écrits en Java. Conclusion : les jeux "à l'heure" sont en C/C++, les jeux "en retard" sont en Java. C'est difficile à avaler ?
java a été utilisé depuis des années dans des jeux commerciaux, comme par exemple Vampire the masquerade qui a remplacé son langage de script proprio par du Java
Super : Java est utilisé comme langage de script et non comme langage principal, ce qui disqualifie complètement l'exemple donné. En plus, Java comme langage de script... J'ose à peine imaginer les difficultés des scripteurs qui ont dû se mettre à Java alors que la programmation avancée n'est pas leur métier.
Et puis, finalement, que le seul exemple que tu trouves est un jeu relativement peu connu (alors que pour C et C++ tu cites Quake 3 et Doom 3 ;-)) ne fait que confirmer que Java n'est pas à proprement parler très adapté à la programmation de jeux. Il y a de mauvaises décisions partout, mais le fait que l'immense majorité des jeux "actuels" (par opposition aux jeux "en retard") soient actuellement codés en C ou C++ ne laisse guère de doute sur l'intérêt de Java dans le domaine, n'est-ce pas ?
De plus, Java est très utilisé en embarqué
Ah oui, quand on parle de jeux temps réel et d'interfaces graphiques sur un PC de bureau, le démineur en Java sur un téléphone portable est un argument très pertinent.
Il y a quelques années, tout le monde disait qu'il fallait faire les jeux en assembleur
"Quelques années" = 10 ans au moins. Le C et le C++ sont bien installés dans les studios de jeux depuis des années.
Ensuite on est passé au C et maitenant tous les moteurs sont en C++
La différence, c'est que la plupart du code généré en C ou C++ est meilleur que le code qu'aurait programmé un humain en assembleur. Cependant, je te rassure, il y a toujours des parties critiques codées en assembleur (notamment, les transformations 3D gagnent à utiliser le SSE... évidemment avec les vertex shaders ce sera bientôt dépassé).
Tu connais des jeux open sources qui sont au niveau des jeux commerciaux ?
On retourne donc la question : tu connais des jeux commerciaux qui sont programmés en Java ?
Tu sais très bien que seul le C affiche les pixels de façon directe
Alors ça veut dire quoi "100% pur Java" dans ta phrase d'origine ?
Tu reconnais finalement avoir dit des âneries, c'est bien ;)
Enfin, SDL, la bibliothèque C sur laquelle est basée FrozenBubble en Perl est destinée à la programmation de jeu. Le blitting des sprites est écrit en assembleur, par exemple.
Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?
Trouver là dedans une preuve des performances de Perl est bien sur ridicule
Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?
C'est quoi le rapport avec la choucroute à par dénigrer gratuitement le travail des autres
Oh rien, je ne fais que sous-entendre que manipuler quelques dizaines de triangles simultanés ne doit pas être trop lourd pour une machine moderne, même avec un langage poussif... Et comme la complexité graphique du rendu (texturages, etc.) est dévolue à OpenGL ou à l'accélération matérielle, cela ne rentre de toute façon pas en ligne de compte dans le travail dévolu à Java.
Le rendu d'arkanae est plus complexe que celui de Frozen Bubble
Sans définition de la "complexité" d'un rendu cela ne veut pas dire grand'chose de chercher à comparer 2D et 3D. Et puis, après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot. Mais bon, si ça peut te permettre d'évacuer un excédent de fougue :)
Je vois deux possibilité : ou FT s'est enfin décidé à agir face à la concurrence (autre opérateurs via le satellite notamment) ou bien ils bluffent afin d'inciter les gens à attendre l'ADSL plutôt que de les laisser s'installer une parabole.
Troisième possibilité : face à l'endettement de FT, l'Etat a mis quelques conditions en échange de sa bienveillance....
Hé ben, pour une fois que je ne tapais pas sur Java... ;)
je me souvient d'une phrase genre "VB ou Java, enfin un langage de neuneu quoi"
J'ai dit ça ? Je devais être dans un grand jour :-))
Ceci dit, et tout troll mis à part, les interfaces graphiques réalisées en Visual Basic répondent en général bien mieux que celles faites en Java. (et pour appeler des routines externes, VB s'interface naturellement avec COM)
Il marche très bien en 100% pur Java alors que pour Perl, c'est basé sur SDL
Ah, les sprites FB sont affichés pixel par pixel en "100% pur Java", peut-être ? Il n'y a pas la moindre bibliothèque en-dessous ? Je suis scié.
Et c'est sûr que le rendu graphique de Frozen Bubble est comparable à celui de Arkanae.
On s'en fout, puisque le rendu graphique est effectué par une lib en natif. Ce qui compte, c'est le moteur de jeu.
Du reste au vu des screenshots l'environnement 3D d'Arkanae est extrêmement pauvre vis-à-vis de ce qui se fait dans le genre dans le domaine commercial. M'enfin, chacun son truc.
La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu
C'est sûr qu'en posant comme hypothèse la conclusion à laquelle on veut arriver, y a pas trop de mal à la démontrer :-))
C'est amusant qu'apparemment tu ne penses pas à faire le même raisonnement pour les autres langages. C'est une incapacité à comprendre la relativité d'un argument ?
Il est logique d'implémenter d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces.
Pourquoi Java au lieu de Perl ou C++ ? Il ne me semble pas que Java ait des qualités qui en fassent le langage idéal pour la programmation d'interfaces graphiques.
Il n'y a rien de "logique" là-dedans, c'est simplement que tu aimes Java. Un amateur de Python ou Ocaml te sortira la même phrase au mot près, mais avec Python ou Ocaml à la place de Java. Et il aura aussi raison que toi.
C'est amusant comme quand tu parles de Java tu perds toute crédibilité et pertinence.
Là pour le coup question pertinence tu fais très fort :)
Les utilisateurs de MS Office auront deux options : exiger à Microsoft un support du format OpenOffice, chose que techniquement Microsoft ne peut refuser ; se mettre à OpenOffice.
Un peu naïf. Les utilisateurs MS Office vont dire à leur correspondant : "hého, c'est pas du .doc, je comprends pas ton machin, utilise des outils standard (sic)". Et le correspondant va râler parce que OOo c'est caca, ça ne fait pas le .doc par défaut.
Ou pire, l'utilisateur MS Office ne répondra pas et l'expéditeur sera dans la mouise (par exemple, demande de subvention passée à la trappe, ou client potentiel perdu ;-)).
- Il y'a des gotos en C
- J'ai du rever, mais j'ai deja croise des pointeurs void en C++
Si tu n'aimes pas, tu n'utilises pas (mais les gens raisonnables savent qu'un goto bien placé peut parfois clarifier grandement une sous-routine). Il ne me semble pas compliqué de coder en C++ sans "goto" ni "void *" ;)
[^] # Re: ... et Free dégroupe à Lyon et Grenoble.
Posté par Moby-Dik . En réponse à la dépêche Accélération du rythme de déploiement de l'ADSL. Évalué à 4.
64 octets from 127.0.0.1: icmp_seq=1 ttl=64 time=0.1 ms
Dis, je comprends pas là. Si tu as "64 octets from 127.0.0.1", ça veut dire que tu pinges ta loopback, tu ne passes pas l'interface réseau et encore moins par la connexion ADSL. Qu'est-ce que tu cherches à prouver ? Si tu as des pertes de paquets en local pur, c'est ton système qui foire, pas Free...
(Disclaimer : je ne suis pas chez Free, je m'en balance, Nerim me convient très bien ;-)))
# Re: erreur 404 not found
Posté par Moby-Dik . En réponse au journal erreur 404 not found. Évalué à 2.
Primordial : vérifie que la séquence à la fin des lignes envoyées par le proxy est bien \r\n (et non \n ou \r ou... certains serveurs sont tolérants mais d'autres non).
Fais un telnet en recopiant directement la requête envoyée par le proxy.
Vérifie que le champ Host est correctement renseigné.
Essaie de changer le User-Agent.
Essaie d'ajouter un Referer.
[^] # Re: Accélération du rythme de déploiement de l'ADSL
Posté par Moby-Dik . En réponse à la dépêche Accélération du rythme de déploiement de l'ADSL. Évalué à 1.
[^] # Re: Accélération du rythme de déploiement de l'ADSL
Posté par Moby-Dik . En réponse à la dépêche Accélération du rythme de déploiement de l'ADSL. Évalué à 1.
Quels prix ? Certainement pas l'abonnement téléphonique, qui a constamment augmenté (quand j'étais gosse, c'était 20 balles par mois avec un téléphone inclus en location...).
Or je ne souhaite pas cette abonnement, je n'utilise pas mon téléphone fixe.
La hausse de l'abonnement est précisément motivée par la volonté de compenser les baisses de tarifs des communications téléphoniques, obligatoires pour faire face à la concurrence. Tu te trompes de cible...
payer pour quelque chose qu'on ne demande pas et qu'on utilise pas
La ligne téléphonique, tu l'utilises, banane ;) Elle coûte aussi cher à entretenir si tu fais de l'ADSL que si tu l'utilises pour des communications vocales analogiques !
[^] # plus
Posté par Moby-Dik . En réponse à la dépêche Accélération du rythme de déploiement de l'ADSL. Évalué à 0.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à -1.
Non, je ne vois pas la différence, puisque conceptuellement il n'y en a aucune.
Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Donc tu es train de me dire que si la bibliothèque utilisée est mal programmée, les performances du langage qui appellent la bibliothèque sont plus importantes que si la bibliothèque est bien écrite (en toute logique, c'est l'inverse puisqu'il y a moins d'overhead) ? Tu n'as pas l'impression de raconter n'importe quoi ?
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie. Heureusement que tu finis tous tes messages en disant que tes interlocuteurs sont de mauvaise foi :-)
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame
C'est marrant : pour une fois que je ne dis pas cela, tu te mets en tête de le réfuter. C'est une obsession chez toi ?
Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Mais tu es vraiment crétin, c'est ça ?
Je ne veux pas t'imiter dans l'insulte, mais j'impression que c'est toi qui est trop crétin pour comprendre que :
- je suis d'accord depuis le début que les primitives graphiques sont codées en natif
- c'est précisément l'argument que j'employais pour dire que le "rendu complexe" (je rigole doucement) d'Arkanae ne prouvait rien quant aux performances de Java
l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage)
Voici une URL intéressante :
http://internalmemos.com/memos/memodetails.php?memo_id=1321(...)
C'est supposément un mémo interne Sun Microsystems. Voici un passage qui concerne l'occupation mémoire de Java (les chiffres sont crédibles et restent à peu près valables à mon avis) :
« Given this data, it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
Further examples of what is possible include the compiling OO languages Eiffel and Sather which fit their garbage collector, exception processor and other infrastructure into roughly 400K of resident set. While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%. »
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 1.
Rassure-moi : tu en doutes sérieusement ? Rien qu'entre gcc 2.9x et gcc 3.0, elles ont fait un bond très sensible, et mesuré. De plus le x86 est un processeur peu sympa pour les compilos (jeu d'instructions foisonnant et peu orthogonal, très peu de registres, règles d'optimisation variables d'un processeur à l'autre et parfois délirantes (pipelines U et V du Pentium...)), ce qui fait qu'il y a eu beaucoup de marge pour l'optimisation du code généré. Cf. pgcc (le gcc optimisé Pentium), egcs (forké de gcc à l'époque où celui-ci stagnait en performances)...
Quake III est programmé en C.
Quake 3, étant sorti il y a quatre ans a été commencé il y a encore plus longtemps, et comme il s'agit d'une suite il est probable qu'ils n'aient pas voulu tout remettre à plat. En tout cas à l'époque où Quake 3 était sorti, certains studios travaillaient déjà en C++, et les compilateurs produisaient déjà du code de bonne qualité (en tout cas celui de Visual Studio).
quand le projet gnome a débuté, l'argument principal était que le C++ [...]
Que viennent faire ici les prétextes peu crédibles du projet Gnome ? Tout le monde sait que Gnome a été créé 1) à cause de la licence de Qt à l'époque 2) parce que RMS et MDI voulaient leur propre desktop (syndrome Not Invented Here + ego surgonflé des deux Messieurs).
mais avec le fait que les jeux open source sont ou bien moches ou bien avec des dessins très mignons (comme frozen bubble), mais très en retard sur les jeux actuels
Oui. Et je te réponds que les "jeux actuels" ne sont pas écrits en Java. Conclusion : les jeux "à l'heure" sont en C/C++, les jeux "en retard" sont en Java. C'est difficile à avaler ?
java a été utilisé depuis des années dans des jeux commerciaux, comme par exemple Vampire the masquerade qui a remplacé son langage de script proprio par du Java
Super : Java est utilisé comme langage de script et non comme langage principal, ce qui disqualifie complètement l'exemple donné. En plus, Java comme langage de script... J'ose à peine imaginer les difficultés des scripteurs qui ont dû se mettre à Java alors que la programmation avancée n'est pas leur métier.
Et puis, finalement, que le seul exemple que tu trouves est un jeu relativement peu connu (alors que pour C et C++ tu cites Quake 3 et Doom 3 ;-)) ne fait que confirmer que Java n'est pas à proprement parler très adapté à la programmation de jeux. Il y a de mauvaises décisions partout, mais le fait que l'immense majorité des jeux "actuels" (par opposition aux jeux "en retard") soient actuellement codés en C ou C++ ne laisse guère de doute sur l'intérêt de Java dans le domaine, n'est-ce pas ?
De plus, Java est très utilisé en embarqué
Ah oui, quand on parle de jeux temps réel et d'interfaces graphiques sur un PC de bureau, le démineur en Java sur un téléphone portable est un argument très pertinent.
Surtout que de tes propres dires : http://linuxfr.org/comments/220801,1.html(...)
La RAM, en embarqué, trop facile d'en ajouter ;)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à -1.
"Quelques années" = 10 ans au moins. Le C et le C++ sont bien installés dans les studios de jeux depuis des années.
Ensuite on est passé au C et maitenant tous les moteurs sont en C++
La différence, c'est que la plupart du code généré en C ou C++ est meilleur que le code qu'aurait programmé un humain en assembleur. Cependant, je te rassure, il y a toujours des parties critiques codées en assembleur (notamment, les transformations 3D gagnent à utiliser le SSE... évidemment avec les vertex shaders ce sera bientôt dépassé).
Tu connais des jeux open sources qui sont au niveau des jeux commerciaux ?
On retourne donc la question : tu connais des jeux commerciaux qui sont programmés en Java ?
Allez, game over ;)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à -1.
Alors ça veut dire quoi "100% pur Java" dans ta phrase d'origine ?
Tu reconnais finalement avoir dit des âneries, c'est bien ;)
Enfin, SDL, la bibliothèque C sur laquelle est basée FrozenBubble en Perl est destinée à la programmation de jeu. Le blitting des sprites est écrit en assembleur, par exemple.
Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?
Trouver là dedans une preuve des performances de Perl est bien sur ridicule
Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?
C'est quoi le rapport avec la choucroute à par dénigrer gratuitement le travail des autres
Oh rien, je ne fais que sous-entendre que manipuler quelques dizaines de triangles simultanés ne doit pas être trop lourd pour une machine moderne, même avec un langage poussif... Et comme la complexité graphique du rendu (texturages, etc.) est dévolue à OpenGL ou à l'accélération matérielle, cela ne rentre de toute façon pas en ligne de compte dans le travail dévolu à Java.
Le rendu d'arkanae est plus complexe que celui de Frozen Bubble
Sans définition de la "complexité" d'un rendu cela ne veut pas dire grand'chose de chercher à comparer 2D et 3D. Et puis, après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot. Mais bon, si ça peut te permettre d'évacuer un excédent de fougue :)
[^] # Re: Accélération du rythme de déploiement de l'ADSL
Posté par Moby-Dik . En réponse à la dépêche Accélération du rythme de déploiement de l'ADSL. Évalué à 7.
[^] # Re: windows ROXOR :)
Posté par Moby-Dik . En réponse au journal windows ROXOR :). Évalué à 0.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 0.
je me souvient d'une phrase genre "VB ou Java, enfin un langage de neuneu quoi"
J'ai dit ça ? Je devais être dans un grand jour :-))
Ceci dit, et tout troll mis à part, les interfaces graphiques réalisées en Visual Basic répondent en général bien mieux que celles faites en Java. (et pour appeler des routines externes, VB s'interface naturellement avec COM)
[^] # Re: Stable comme Linux ?
Posté par Moby-Dik . En réponse au journal Stable comme Linux ?. Évalué à 3.
[^] # Re: La programmation clusterisée à la porte de tous ? Un livre sur Erlang
Posté par Moby-Dik . En réponse à la dépêche La programmation clusterisée à la portée de tous ? Un livre sur Erlang. Évalué à 1.
Pour Mickaël : Un serveur n'est finalement qu'une fonction récursive qui stocke son état dans les paramètres de la fonction.
Oui, c'est une machine de Turing, aussi ;)
[^] # Re: Comment ca va ? Java bien
Posté par Moby-Dik . En réponse au journal Comment ca va ? Java bien. Évalué à 1.
Hum ;)
[^] # Re: A propos de spip
Posté par Moby-Dik . En réponse au journal A propos de spip. Évalué à 1.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 0.
Ah, les sprites FB sont affichés pixel par pixel en "100% pur Java", peut-être ? Il n'y a pas la moindre bibliothèque en-dessous ? Je suis scié.
Et c'est sûr que le rendu graphique de Frozen Bubble est comparable à celui de Arkanae.
On s'en fout, puisque le rendu graphique est effectué par une lib en natif. Ce qui compte, c'est le moteur de jeu.
Du reste au vu des screenshots l'environnement 3D d'Arkanae est extrêmement pauvre vis-à-vis de ce qui se fait dans le genre dans le domaine commercial. M'enfin, chacun son truc.
La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu
C'est sûr qu'en posant comme hypothèse la conclusion à laquelle on veut arriver, y a pas trop de mal à la démontrer :-))
C'est amusant qu'apparemment tu ne penses pas à faire le même raisonnement pour les autres langages. C'est une incapacité à comprendre la relativité d'un argument ?
Il est logique d'implémenter d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces.
Pourquoi Java au lieu de Perl ou C++ ? Il ne me semble pas que Java ait des qualités qui en fassent le langage idéal pour la programmation d'interfaces graphiques.
Il n'y a rien de "logique" là-dedans, c'est simplement que tu aimes Java. Un amateur de Python ou Ocaml te sortira la même phrase au mot près, mais avec Python ou Ocaml à la place de Java. Et il aura aussi raison que toi.
C'est amusant comme quand tu parles de Java tu perds toute crédibilité et pertinence.
Là pour le coup question pertinence tu fais très fort :)
[^] # Re: Mise en place du Réseau Indépendant d'Hébergeurs Autogérés
Posté par Moby-Dik . En réponse à la dépêche Mise en place du Réseau Indépendant d'Hébergeurs Autogérés. Évalué à 0.
[^] # Re: Ximian Desktop 2 est disponible
Posté par Moby-Dik . En réponse à la dépêche Ximian Desktop 2 est disponible. Évalué à 1.
Un peu naïf. Les utilisateurs MS Office vont dire à leur correspondant : "hého, c'est pas du .doc, je comprends pas ton machin, utilise des outils standard (sic)". Et le correspondant va râler parce que OOo c'est caca, ça ne fait pas le .doc par défaut.
Ou pire, l'utilisateur MS Office ne répondra pas et l'expéditeur sera dans la mouise (par exemple, demande de subvention passée à la trappe, ou client potentiel perdu ;-)).
# Re: A propos de spip
Posté par Moby-Dik . En réponse au journal A propos de spip. Évalué à 1.
[^] # Re: SuSE remplace Mandrake chez Wallmart
Posté par Moby-Dik . En réponse à la dépêche SuSE remplace Mandrake chez Wal-Mart. Évalué à 2.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 1.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 2.
Pour preuve : Frozen Bubble.
[^] # Re: Comment ca va ? Java bien
Posté par Moby-Dik . En réponse au journal Comment ca va ? Java bien. Évalué à 1.
- J'ai du rever, mais j'ai deja croise des pointeurs void en C++
Si tu n'aimes pas, tu n'utilises pas (mais les gens raisonnables savent qu'un goto bien placé peut parfois clarifier grandement une sous-routine). Il ne me semble pas compliqué de coder en C++ sans "goto" ni "void *" ;)
# Re: Comment ca va ? Java bien
Posté par Moby-Dik . En réponse au journal Comment ca va ? Java bien. Évalué à 0.