Entre 150 fps et 50 fps (en valeur minimale), pour un jeu comme frozen bubble, il est impossible de faire la différence
D'où vient cette manie de se restreindre à un domaine réduit quand on répond à une affirmation générale ? Ah oui, c'est vrai : tu comprends que ton argument est foireux, donc tu déplaces la discussion. Comme si personne n'avait rien vu ;)
A propos de fps, un autre intervenant a posté des chiffres factuels sur les performances d'un Quake en Java. Je suis sûr que tu auras à coeur de trouver de multiples excuses aux performances pour le moins faiblardes de cette version (largement inférieures à 50 fps). Et puis : si ton jeu tourne à 150 fps, ça te permet de descendre à 50 fps avec un jeu trois plus complexe (en affichage, en IA, en moteur physique...). Pas trop dur à comprendre.
Oui, oui, en particulier We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation
Sauf que les chiffres cités pour Solaris sont à peu près égaux à ceux cités ici par d'autres personnes en ce qui concerne Linux (et que tu n'as pas contestés).
D'autre part, je maintiens que la mémoire ne coûte rien sur un PC
Le mémo que je citais (oui, encore une fois) ne parlait pas que de HelloWorld. Il constatait aussi que l'occupation mémoire augmentait beaucoup plus avec la taille des données en Java qu'en Python. De plus l'occupation mémoire a des coûts en terme de performances (cache miss, etc.).
Surtout, tu confonds deux choses : le coût de la mémoire, et la volonté qu'ont les utilisateurs potentiels d'upgrader la mémoire de leur machine. Si une seule appli se met à ramer parce qu'elle a besoin de trop de mémoire, les gens ne vont pas ajouter une barrette (c'est de toute façon au-delà de leurs compétences pour la majorité), ils vont simplement trouver que l'appli n'est pas performante.
L'adoption de Java sur les téléphones portables me semble assez symptomatique. J'ai comme l'impression que les fabriquants connaissent mieux le problème que toi.
J'ai surtout l'impression que les applis présentes sur un téléphone portable, et les contraintes d'utilisation y afférentes (vu l'ergonomie désastreuse du bidule, pas besoin d'un temps de réaction < 100ms), font que les performances ne sont pas vraiment cruciales sur ce genre de produits. De plus, ces applis ne sont pas "coeur de métier", c'est juste un bonus pour attirer les gogos, la qualité n'est pas importante.
Mais apparamment non, j'ai un manque chronique de connaissances en la matière
Oh, pas du tout. Tu as juste raconté des bêtises sur 1) la soi-disant stagnation des performances des compilateurs C ; 2) le soi-disant peu d'importance des performances CPU dans les jeux modernes ; 3) le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main ; 4) la soi-disant utilisation courante de Java dans les jeux actuels alors que le seul exemple que tu as trouvé ne concerne que l'utilisation en tant que langage de script.
Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison ! Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)
Ah, et le meilleur pour la fin :
j'aime bien les insultes polies
Si tu penses que relever un manque de compétences est une insulte, tu dois être assez susceptible dans la vie quotidienne non ? (tu es libre d'y voir une insulte polie :-))
[^] # 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.
D'où vient cette manie de se restreindre à un domaine réduit quand on répond à une affirmation générale ? Ah oui, c'est vrai : tu comprends que ton argument est foireux, donc tu déplaces la discussion. Comme si personne n'avait rien vu ;)
A propos de fps, un autre intervenant a posté des chiffres factuels sur les performances d'un Quake en Java. Je suis sûr que tu auras à coeur de trouver de multiples excuses aux performances pour le moins faiblardes de cette version (largement inférieures à 50 fps). Et puis : si ton jeu tourne à 150 fps, ça te permet de descendre à 50 fps avec un jeu trois plus complexe (en affichage, en IA, en moteur physique...). Pas trop dur à comprendre.
Oui, oui, en particulier We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation
Sauf que les chiffres cités pour Solaris sont à peu près égaux à ceux cités ici par d'autres personnes en ce qui concerne Linux (et que tu n'as pas contestés).
D'autre part, je maintiens que la mémoire ne coûte rien sur un PC
Le mémo que je citais (oui, encore une fois) ne parlait pas que de HelloWorld. Il constatait aussi que l'occupation mémoire augmentait beaucoup plus avec la taille des données en Java qu'en Python. De plus l'occupation mémoire a des coûts en terme de performances (cache miss, etc.).
Surtout, tu confonds deux choses : le coût de la mémoire, et la volonté qu'ont les utilisateurs potentiels d'upgrader la mémoire de leur machine. Si une seule appli se met à ramer parce qu'elle a besoin de trop de mémoire, les gens ne vont pas ajouter une barrette (c'est de toute façon au-delà de leurs compétences pour la majorité), ils vont simplement trouver que l'appli n'est pas performante.
L'adoption de Java sur les téléphones portables me semble assez symptomatique. J'ai comme l'impression que les fabriquants connaissent mieux le problème que toi.
J'ai surtout l'impression que les applis présentes sur un téléphone portable, et les contraintes d'utilisation y afférentes (vu l'ergonomie désastreuse du bidule, pas besoin d'un temps de réaction < 100ms), font que les performances ne sont pas vraiment cruciales sur ce genre de produits. De plus, ces applis ne sont pas "coeur de métier", c'est juste un bonus pour attirer les gogos, la qualité n'est pas importante.
Mais apparamment non, j'ai un manque chronique de connaissances en la matière
Oh, pas du tout. Tu as juste raconté des bêtises sur 1) la soi-disant stagnation des performances des compilateurs C ; 2) le soi-disant peu d'importance des performances CPU dans les jeux modernes ; 3) le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main ; 4) la soi-disant utilisation courante de Java dans les jeux actuels alors que le seul exemple que tu as trouvé ne concerne que l'utilisation en tant que langage de script.
Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison ! Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)
Ah, et le meilleur pour la fin :
j'aime bien les insultes polies
Si tu penses que relever un manque de compétences est une insulte, tu dois être assez susceptible dans la vie quotidienne non ? (tu es libre d'y voir une insulte polie :-))