Non, n'importe quoi. Si l'overhead apporté par la bibliothèque est moins important, alors l'influence du reste est plus importante relativement au total (c'est des maths, tu sais).
Tu confonds évaluation théorique et réalité pratique, ce qui est très génant pour un jeu. Ce que l'utilisateur voit, c'est la fluidité du jeu, en gros le nombre de frame par seconde. Quand ça tombe en dessous d'un certain niveau, c'est injouable. A partir d'un autre niveau, on ne voit plus la différence. Entre 150 fps et 50 fps (en valeur minimale), pour un jeu comme frozen bubble, il est impossible de faire la différence. Si ta bibliothèque C est bien faite, comme c'est le cas de SDL, tu peux facilement dépasser très largement le minimum syndical. Que le reste de l'application rame un peu ne change pas grand chose car cela représente une part infime des performances de la dite appli. Tu as parfaitement raison de dire que l'influence relative du langage est plus importante quand la bibliothèque est bien faite, mais on s'en fout. L'importance relative n'est pas directement perçu par l'utilisateur, c'est la réactivité de l'ensemble qui compte. Quand tu programmes avec une bibliothèque comme SDL ou OpenGL qui te permets de garantir (ou presque) de bonnes performances, le reste importe peu. A contrario, quand tu utilises une bibliothèque mal faite, il te reste une part très faible du temps CPU disponible entre deux frames et les performances du code utilisé à ce moment sont cruciales pour l'interactivité du jeu. C'est le même problème pour swing. L'utilisateur qui doit attendre une demi-seconde la première fois qu'il clique sur un menu parce qu'il faut byte-compiler la sur-couche swing d'une vague fenêtre motif va être assez ennervé, même si les fonctions complexes déclenchées par le GUI sont exécutées très rapidement.
il suffit de savoir lire
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., mais ça, tu ne risques pas de le citer, n'est-ce pas...
Mais bon, tout ça, c'est trop compliqué, d'ailleurs "Java rulez dans l'embarqué" et "la mémoire a un coût dérisoire, quelle importance si ça en bouffe beaucoup" (sic) n'est-ce pas :-))
Tu ne sembles pas savoir que la J2ME a une occupation mémoire très faible (beaucoup plus faible que celle de la J2SE dont il est question dans ton mémo). 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. D'autre part, je maintiens que la mémoire ne coûte rien sur un PC et donc que les problèmes de la J2SE ne sont pas si graves que ça.
Enfin, bon, ton gros problème est que tu t'es engouffré bille en tête dans une discussion à laquelle tu n'as rien compris mais où il te semblait scandaleux qu'on critiquât Java, n'est-ce pas ? Ayant dû abdiquer le débat sur les jeux video où tu t'es fait ramasser par plusieurs personnes à cause de ton manque chronique de connaissances en la matière, tu es maintenant réduit à lancer des attaques personnelles et à ressasser quelques arguments déjà plusieurs fois réfutés ;)
Oui oui, bien sûr. C'est marrant, mais ayant développé (en C) la gestion du son et la version 2 du pathfinding de freecraft (pas la version 3, je l'avoue), j'avais l'impression d'avoir une vague idée de ce qu'est un jeu. Je pensais aussi que la lecture régulière de gamasutra m'aidait un peu dans cette compréhension. Mais apparamment non, j'ai un manque chronique de connaissances en la matière (j'aime bien les insultes polies, ça m'a toujours fait beaucoup rire. Je suis plus direct, en général, mais bon, je respecte l'art de l'insulte polie). D'autre part, tu devrais relire https://linuxfr.org/comments/221368.html(...) Peut être que tu ne comprends pas ma première phrase, mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.
Allez, va, c'est ma dernière réponse, je ne peux pas lutter contre un grand réfutateur d'argument qui connaît si bien le jeu vidéo.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à -1.
Tu confonds évaluation théorique et réalité pratique, ce qui est très génant pour un jeu. Ce que l'utilisateur voit, c'est la fluidité du jeu, en gros le nombre de frame par seconde. Quand ça tombe en dessous d'un certain niveau, c'est injouable. A partir d'un autre niveau, on ne voit plus la différence. Entre 150 fps et 50 fps (en valeur minimale), pour un jeu comme frozen bubble, il est impossible de faire la différence. Si ta bibliothèque C est bien faite, comme c'est le cas de SDL, tu peux facilement dépasser très largement le minimum syndical. Que le reste de l'application rame un peu ne change pas grand chose car cela représente une part infime des performances de la dite appli. Tu as parfaitement raison de dire que l'influence relative du langage est plus importante quand la bibliothèque est bien faite, mais on s'en fout. L'importance relative n'est pas directement perçu par l'utilisateur, c'est la réactivité de l'ensemble qui compte. Quand tu programmes avec une bibliothèque comme SDL ou OpenGL qui te permets de garantir (ou presque) de bonnes performances, le reste importe peu. A contrario, quand tu utilises une bibliothèque mal faite, il te reste une part très faible du temps CPU disponible entre deux frames et les performances du code utilisé à ce moment sont cruciales pour l'interactivité du jeu. C'est le même problème pour swing. L'utilisateur qui doit attendre une demi-seconde la première fois qu'il clique sur un menu parce qu'il faut byte-compiler la sur-couche swing d'une vague fenêtre motif va être assez ennervé, même si les fonctions complexes déclenchées par le GUI sont exécutées très rapidement.
il suffit de savoir lire
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., mais ça, tu ne risques pas de le citer, n'est-ce pas...
Mais bon, tout ça, c'est trop compliqué, d'ailleurs "Java rulez dans l'embarqué" et "la mémoire a un coût dérisoire, quelle importance si ça en bouffe beaucoup" (sic) n'est-ce pas :-))
Tu ne sembles pas savoir que la J2ME a une occupation mémoire très faible (beaucoup plus faible que celle de la J2SE dont il est question dans ton mémo). 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. D'autre part, je maintiens que la mémoire ne coûte rien sur un PC et donc que les problèmes de la J2SE ne sont pas si graves que ça.
Enfin, bon, ton gros problème est que tu t'es engouffré bille en tête dans une discussion à laquelle tu n'as rien compris mais où il te semblait scandaleux qu'on critiquât Java, n'est-ce pas ? Ayant dû abdiquer le débat sur les jeux video où tu t'es fait ramasser par plusieurs personnes à cause de ton manque chronique de connaissances en la matière, tu es maintenant réduit à lancer des attaques personnelles et à ressasser quelques arguments déjà plusieurs fois réfutés ;)
Oui oui, bien sûr. C'est marrant, mais ayant développé (en C) la gestion du son et la version 2 du pathfinding de freecraft (pas la version 3, je l'avoue), j'avais l'impression d'avoir une vague idée de ce qu'est un jeu. Je pensais aussi que la lecture régulière de gamasutra m'aidait un peu dans cette compréhension. Mais apparamment non, j'ai un manque chronique de connaissances en la matière (j'aime bien les insultes polies, ça m'a toujours fait beaucoup rire. Je suis plus direct, en général, mais bon, je respecte l'art de l'insulte polie). D'autre part, tu devrais relire https://linuxfr.org/comments/221368.html(...) Peut être que tu ne comprends pas ma première phrase, mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.
Allez, va, c'est ma dernière réponse, je ne peux pas lutter contre un grand réfutateur d'argument qui connaît si bien le jeu vidéo.