Combien de ram utilise la version Java (un pauvre top devrait suffire) ?
Résultats de "top"
Version Java :
- VIRT : 127m
- RES : 81m
Version C :
- VIRT : 61884
- RES : 26m
Quake 3:
- VIRT : 81132
- RES : 45m
A noter que l'occupation mémoire de la version Java continue à augmenter régulièrement après le lancement. On passe de 115m à 127m en moins d'une minute. Ca reste stable pour la version C et pour Quake 3.
Quelle JVM et quelle option de démarrage ?
La JVM est la 1.4.1_03 de Sun, c'est celle qui est fournie avec l'archive ri_preview_linux.tar.bz2 disponible sur le site du projet. Pour tester la version C, j'utilise le paquet quake-gl de la Debian/unstable, avec les options width 640, height 480, vid_glx_fullscreen 1 et show_fps 1 pour être dans les mêmes conditions.
Ligne de démarrage :
jre/bin/java -cp launcher.jar -Djava.ext.dirs=lib -Djava.library.path=lib/os/linux -ms150m -mx150m -XX:CompileThreshold=5 -Xincgc -XX:-PrintGCDetails com.realityinteractive.demo.launcher.Launcher
Quel système ?
Debian/unstable, kernel 2.4.20 compilé avec gcc 3.2 pour K6 avec un nombre limité de pilotes.
Les différences sont étonnantes parce que l'implémentation est normalement basée sur un pont opengl (pas le même que arkanae) et pourtant, c'est vraiment tout pourri...
Oui, c'est vraiment étonnant, comme quoi dans Quake, il semblerait qu'il n'y a pas que le rendu 3d qui compte. Sans oublier le fait que la version Java est une démo non jouable contrairement à la version C.
Dernière remarque, les auteurs de la version Java disent que leur rendu est meilleur. Qu'en penses-tu ?
Personnellement, je n'ai pas vu de différence visuelle entre les deux. Il y en a peut-être une, mais elle n'est pas assez évidente pour être remarquée au premier coup d'oeil. En tout cas, on voit une différence très nette avec Quake 3, qui tourne lui à 30/40 fps sur la même machine.
Si quelqu'un pouvait tester sur une autre machine, ça donnerait peut être un meilleur point de vue. Etant donné l'occupation mémoire de la version Java, mes 128 Mo de mémoire vive sont sans doute un peu justes. Et s'ils utilisent des extensions non disponibles sur ma TNT2, tester les deux versions sur une GeForce/Radeon permettrait d'être fixé.
Il n'en reste pas moins que la différence entre les deux versions est assez énorme. Un simple Pentium 90/16Mo suffit à faire tourner la version C alors qu'il faut un Pentium 500/256 Mo pour faire tourner la version Java. Je veux bien que les développeurs ne soient pas au niveau de ceux d'id Software, mais le code source de Quake est disponible depuis un bon bout de temps et ils ont eu tout le loisir de l'étudier et de l'améliorer. Sans oublier le fait qu'un jeu comme Cube développé indépendemment par un amateur (en C++) tourne très bien sur ma machine et offre un rendu plus proche de Quake 2.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Frédéric Lopez . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 2.
Résultats de "top"
Version Java :
- VIRT : 127m
- RES : 81m
Version C :
- VIRT : 61884
- RES : 26m
Quake 3:
- VIRT : 81132
- RES : 45m
A noter que l'occupation mémoire de la version Java continue à augmenter régulièrement après le lancement. On passe de 115m à 127m en moins d'une minute. Ca reste stable pour la version C et pour Quake 3.
Quelle JVM et quelle option de démarrage ?
La JVM est la 1.4.1_03 de Sun, c'est celle qui est fournie avec l'archive ri_preview_linux.tar.bz2 disponible sur le site du projet. Pour tester la version C, j'utilise le paquet quake-gl de la Debian/unstable, avec les options width 640, height 480, vid_glx_fullscreen 1 et show_fps 1 pour être dans les mêmes conditions.
Ligne de démarrage :
jre/bin/java -cp launcher.jar -Djava.ext.dirs=lib -Djava.library.path=lib/os/linux -ms150m -mx150m -XX:CompileThreshold=5 -Xincgc -XX:-PrintGCDetails com.realityinteractive.demo.launcher.Launcher
Quel système ?
Debian/unstable, kernel 2.4.20 compilé avec gcc 3.2 pour K6 avec un nombre limité de pilotes.
Les différences sont étonnantes parce que l'implémentation est normalement basée sur un pont opengl (pas le même que arkanae) et pourtant, c'est vraiment tout pourri...
Oui, c'est vraiment étonnant, comme quoi dans Quake, il semblerait qu'il n'y a pas que le rendu 3d qui compte. Sans oublier le fait que la version Java est une démo non jouable contrairement à la version C.
Dernière remarque, les auteurs de la version Java disent que leur rendu est meilleur. Qu'en penses-tu ?
Personnellement, je n'ai pas vu de différence visuelle entre les deux. Il y en a peut-être une, mais elle n'est pas assez évidente pour être remarquée au premier coup d'oeil. En tout cas, on voit une différence très nette avec Quake 3, qui tourne lui à 30/40 fps sur la même machine.
Si quelqu'un pouvait tester sur une autre machine, ça donnerait peut être un meilleur point de vue. Etant donné l'occupation mémoire de la version Java, mes 128 Mo de mémoire vive sont sans doute un peu justes. Et s'ils utilisent des extensions non disponibles sur ma TNT2, tester les deux versions sur une GeForce/Radeon permettrait d'être fixé.
Il n'en reste pas moins que la différence entre les deux versions est assez énorme. Un simple Pentium 90/16Mo suffit à faire tourner la version C alors qu'il faut un Pentium 500/256 Mo pour faire tourner la version Java. Je veux bien que les développeurs ne soient pas au niveau de ceux d'id Software, mais le code source de Quake est disponible depuis un bon bout de temps et ils ont eu tout le loisir de l'étudier et de l'améliorer. Sans oublier le fait qu'un jeu comme Cube développé indépendemment par un amateur (en C++) tourne très bien sur ma machine et offre un rendu plus proche de Quake 2.