Tu es très fort, tu arrives à me faire aller à l'encontre de mes bonnes résolutions.
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 ;)
Mais bien sûr. J'ai dit :
La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu
mais voir qu'on peut faire aussi bien en Java sans passer par une optimisation de très bas niveau, prouve effectivement que Java fonctionne correctement.
SDL est une super bibliothèque très optimisée qui est interfacée correctement avec Perl, d'où de bonnes performances. Mais on peut faire aussi jouable en Java sans assembleur, sans accès direct à la mémoire vidéo, etc. De même, OpenGL est super optimisé et remarquablement bien interfacée avec Java, ce qui permet de programmer objet tout en obtenant d'excellentes performances.
De très nombreux langages ont choisis de se baser sur gtk avec des performances excellentes. De même, les performances de swt en Java sont très bonnes. J'en déduis donc que le probème de swing n'est pas Java, mais swing. Si tu ne comprends pas, je n'y peux rien.
si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
De ce fait, avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage
etc., je ne vais pas recopier intégralement des posts que tu ne lis pas. Maintenant, cherche bien là dedans (et dans le reste) et dis moi à quel moment j'ai nié ton histoire d'importance relative du langage. C'est toi qui a écrit que je pensais le contraire.
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, ou encore de descendre à 50 fps si le reste du jeu est implémenté dans un langage qui rame. Bravo, tu as compris ce que je me tue à t'expliquer depuis plusieurs posts (cf avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage).
la soi-disant stagnation des performances des compilateurs C
Ton super exemple est gcc (très utilisé pour compiler les jeux commerciaux), pour lequel je veux bien croire que les performances ont augmenté, heureusement, malgré ses nombreuses qualités gcc a toujours été très en retard sur les compilateurs commerciaux (par exemple sur alpha, c'était une catastrophe). J'aimerais savoir quelle a été la progression des compilateurs C commerciaux sur les 10 dernières années (pour le C++, la progression est énorme). Ton autre super argument est la prise compte d'un hardware moderne. Formidable. C'est aussi le cas dans tous les autres langages. De toute manière, je suis persuadé que les compilateurs C ont très peu progressé par rapport aux compilateurs C++ et à la JVM.
Ceci étant, pour te faire plaisir, je veux bien dire que j'ai dit une connerie.
le soi-disant peu d'importance des performances CPU dans les jeux modernes
J'ai dit De plus, le discours sur les performances me fait bien rire.. C'est bizarre mais j'ai l'impression que ce n'est pas exactement la même chose. Et je maintiens que Carmack a été très réticent pendant des années à passer au C++ pour des raisons de performances et de bugs des compilateurs. Or, aujourd'hui, plus personne ne critique le choix du C++ pour programmer l'essentiel d'un jeu. Mon argument était juste de dire que je pense que dans quelques années (disons j'espère), l'argument "Java ça rame" sera devenu aussi pertinent que celui "C++ ça rame".
le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main
Alors la, bravo. Trouve moi la citation qu'on rigole. Et ensuite, va lire les articles sur ATLAS pour voir ce qu'on peut gagner en passant à l'assembleur (par rapport au C). Les programmeurs codent les jeux en C++ parce que la perte de performance est largement compensée par le hardware actuel et les économies en temps de développement, pas parce qu'ils sont sur que l'assembleur engendré est aussi bon que ce qu'ils pourraient faire à la main. Et je ne connais pas de bench significatif concernant la qualité du code engendré (les parties d'ATLAS concernées sont très spécifiques).
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.
Aller, trouve moi la citation qu'on rigole de nouveau.
Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison !
Je suppose que tu travailles dans un grand studio de développement de jeux (et tu ne connais pas Vampire The masquerade ?). Parce que sinon, tu fais comment pour savoir ce qui est utilisé comme techno dans les logiciels propriétaires que sont les jeux ? Personnellement, je lis gamasutra. Mais c'est vrai que je suis incompétent.
Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)
Ba oui, c'est d'ailleurs exactement ce que j'ai dit (tu dois pouvoir trouver la citation quelque part). D'ailleurs, c'est sûrement pour rien que j'ai dit mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.
Tu peux toujours faire de l'ironie à deux centimes. J'ai juste voulu indiquer que j'avais quelques compétences en jeux vidéo, contrairement à ce que tu affirmes. Quelles sont les tiennes, à part une grande bouche ?
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 :-))
D'après le grand robert, crétin signifie "personne sotte, stupide". Je te suggère donc de remplacer dans mes phrases "tu es un crétin" par "tes arguments sont stupides". C'est plus long et moins direct, et éventuellement un peu moins une généralisation hâtive (c'est vrai que tu utilises peut être des arguments intelligents dans d'autres contextes). Au final, tu obtiendras ce que j'appelles une insulte polie, mais ça ne semble pas te gêner, alors allons pour l'insulte polie.
[^] # 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.
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 ;)
Mais bien sûr. J'ai dit :
La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu
mais voir qu'on peut faire aussi bien en Java sans passer par une optimisation de très bas niveau, prouve effectivement que Java fonctionne correctement.
SDL est une super bibliothèque très optimisée qui est interfacée correctement avec Perl, d'où de bonnes performances. Mais on peut faire aussi jouable en Java sans assembleur, sans accès direct à la mémoire vidéo, etc. De même, OpenGL est super optimisé et remarquablement bien interfacée avec Java, ce qui permet de programmer objet tout en obtenant d'excellentes performances.
De très nombreux langages ont choisis de se baser sur gtk avec des performances excellentes. De même, les performances de swt en Java sont très bonnes. J'en déduis donc que le probème de swing n'est pas Java, mais swing. Si tu ne comprends pas, je n'y peux rien.
si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
De ce fait, avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage
etc., je ne vais pas recopier intégralement des posts que tu ne lis pas. Maintenant, cherche bien là dedans (et dans le reste) et dis moi à quel moment j'ai nié ton histoire d'importance relative du langage. C'est toi qui a écrit que je pensais le contraire.
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, ou encore de descendre à 50 fps si le reste du jeu est implémenté dans un langage qui rame. Bravo, tu as compris ce que je me tue à t'expliquer depuis plusieurs posts (cf avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage).
la soi-disant stagnation des performances des compilateurs C
Ton super exemple est gcc (très utilisé pour compiler les jeux commerciaux), pour lequel je veux bien croire que les performances ont augmenté, heureusement, malgré ses nombreuses qualités gcc a toujours été très en retard sur les compilateurs commerciaux (par exemple sur alpha, c'était une catastrophe). J'aimerais savoir quelle a été la progression des compilateurs C commerciaux sur les 10 dernières années (pour le C++, la progression est énorme). Ton autre super argument est la prise compte d'un hardware moderne. Formidable. C'est aussi le cas dans tous les autres langages. De toute manière, je suis persuadé que les compilateurs C ont très peu progressé par rapport aux compilateurs C++ et à la JVM.
Ceci étant, pour te faire plaisir, je veux bien dire que j'ai dit une connerie.
le soi-disant peu d'importance des performances CPU dans les jeux modernes
J'ai dit De plus, le discours sur les performances me fait bien rire.. C'est bizarre mais j'ai l'impression que ce n'est pas exactement la même chose. Et je maintiens que Carmack a été très réticent pendant des années à passer au C++ pour des raisons de performances et de bugs des compilateurs. Or, aujourd'hui, plus personne ne critique le choix du C++ pour programmer l'essentiel d'un jeu. Mon argument était juste de dire que je pense que dans quelques années (disons j'espère), l'argument "Java ça rame" sera devenu aussi pertinent que celui "C++ ça rame".
le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main
Alors la, bravo. Trouve moi la citation qu'on rigole. Et ensuite, va lire les articles sur ATLAS pour voir ce qu'on peut gagner en passant à l'assembleur (par rapport au C). Les programmeurs codent les jeux en C++ parce que la perte de performance est largement compensée par le hardware actuel et les économies en temps de développement, pas parce qu'ils sont sur que l'assembleur engendré est aussi bon que ce qu'ils pourraient faire à la main. Et je ne connais pas de bench significatif concernant la qualité du code engendré (les parties d'ATLAS concernées sont très spécifiques).
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.
Aller, trouve moi la citation qu'on rigole de nouveau.
Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison !
Je suppose que tu travailles dans un grand studio de développement de jeux (et tu ne connais pas Vampire The masquerade ?). Parce que sinon, tu fais comment pour savoir ce qui est utilisé comme techno dans les logiciels propriétaires que sont les jeux ? Personnellement, je lis gamasutra. Mais c'est vrai que je suis incompétent.
Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)
Ba oui, c'est d'ailleurs exactement ce que j'ai dit (tu dois pouvoir trouver la citation quelque part). D'ailleurs, c'est sûrement pour rien que j'ai dit mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.
Tu peux toujours faire de l'ironie à deux centimes. J'ai juste voulu indiquer que j'avais quelques compétences en jeux vidéo, contrairement à ce que tu affirmes. Quelles sont les tiennes, à part une grande bouche ?
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 :-))
D'après le grand robert, crétin signifie "personne sotte, stupide". Je te suggère donc de remplacer dans mes phrases "tu es un crétin" par "tes arguments sont stupides". C'est plus long et moins direct, et éventuellement un peu moins une généralisation hâtive (c'est vrai que tu utilises peut être des arguments intelligents dans d'autres contextes). Au final, tu obtiendras ce que j'appelles une insulte polie, mais ça ne semble pas te gêner, alors allons pour l'insulte polie.