Pour rappel, Neverball est un jeu d'action / adresse en 3D dans lequel le joueur contrôle une balle en inclinant le plateau de jeu à l'aide de la souris ou tout autre périphérique de contrôle (clavier, joystick, Wiimote...).
Pour le rendu 3D, Nuncabola s'appuie sur la bibliothèque LWJGL (Lightweight Java Game Library, licence BSD), il utilise également JInput et JOrbis.
Les performances du jeu sont excellentes, et il tourne n'importe où, du moment que vous avez une machine virtuelle java (JRE) en version 5 ou 6 et une 3D accélérée pas trop vieille.
Les dépendances sont incluses à l'archive. L'auteur se surnomme Elviz, c'est un contributeur régulier de Neverball, surtout en création de niveaux (la collection Nevermania, niveaux pour experts malsains confirmés), mais aussi un peu en code source.
C'est par ailleurs un excellent joueur, il détient à l'heure actuelle le plus grand nombre de records sur la Nevertable (table des records en ligne).
Elviz était gêné par un petit défaut de Neverball : un léger manque de fluidité dû à un problème dans la gestion de la physique. Ce fut la principale raison qui l'a poussé à se lancer dans le développement de Nuncabola, nom qui signifie Neverball en portugais, même si Elviz est allemand !
L'auteur n'a pas communiqué sur son logiciel en dehors du forum car, étant extrêmement perfectionniste, il ne souhaite le faire que lorsque son jeu aura atteint la qualité suffisante à ses yeux. De par mon expérience, il est d'une stabilité comparable à celle de Neverball.
Nuncabola évolue depuis déjà plus de 8 mois, et je trouve dommage qu'il reste peu connu compte tenu de sa finition, mais aussi parce que c'est un des rares jeux 3D Java libres de cette qualité. Et puis c'est du libre, donc pourquoi attendre pour partager ?
Depuis sa première version, Nuncabola évolue avec Neverball, l'un empruntant à l'autre les évolutions compatibles.
Les films (replays) de records sont parfaitement compatibles avec les dernières versions de Neverball.
Toutes les fonctionnalités de Neverball ne sont cependant pas implémentées, il manque notamment : la localisation (seul l'anglais est pris en charge), le compilateur de niveaux (mapc) et la gestion des périphériques d'inclinaison (comme la Wiimote).
Le jeu n'a pas non plus d'installateur, il se lance en passant le fichier jar à la machine virtuelle java.
Font aussi défaut un site officiel et une implémentation java de Neverputt ! (le mini-golf)
Aller plus loin
- Nuncabola (59 clics)
- Neverball (19 clics)
- Neverball sur jeuxlibres.net (20 clics)
- LWJGL (8 clics)
- Nevertable (6 clics)
# LWJGL
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: LWJGL
Posté par zerkman (site web personnel) . Évalué à 5.
[^] # Re: LWJGL
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: LWJGL
Posté par zerkman (site web personnel) . Évalué à 4.
[^] # Re: LWJGL
Posté par BAud (site web personnel) . Évalué à 4.
[^] # Re: LWJGL
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
- Java s'installe avec un ensemble de bibliothèques standards de bas et de haut niveau : JRE (ou plutôt J2SE selon le vocabulaire en vigueur). Ca va des entrées/sorties aux interfaces graphiques en passant par les accès aux bases de données. C'est un peu fourre tout, mais ça facilite énormément le travail de déploiement de logiciel sur de multiples plateformes. Le problème c'est que pour les jeux, il n'y a qu'une bibliothèque graphique 2D assez lente fournie en standard (Java2D). LWJGL, qui fournit un accès à la bibliothèque graphique 3D OpenGL, rendrait la distribution de jeux Java beaucoup plus facile.
- en C, il n'y a pas d'équivalent au J2SE. Il y a juste une bibliothèque standard très très réduite.
Ces deux situations sont forts regrettables pour le développeur de jeux, mais autant on peut espérer une évolution du J2SE, autant on est CERTAIN que jamais on ne verra la libc inclure OpenGL : pour des raisons pratiques et historiques ce n'est ni souhaitable, ni faisable.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: LWJGL
Posté par zerkman (site web personnel) . Évalué à 7.
Mon allusion à l'inclusion de SDL et OpenGL dans la libc étaient bien entendu sarcastiques, car autant la disponibilité de fonctions d'entrées/sorties de base, d'allocation mémoire et de gestion de données simples (chaînes de caractères ...) sont indispensables, autant l'inclusion de tout un paquet de fonctionnalités dont on ne se servira à peine de 5% de l'ensemble, et dont certaines font double emploi (AWT et Swing notamment), c'est n'importe quoi.
Ces deux situations sont forts regrettables pour le développeur de jeux
Il ne faudrait tout de même pas prendre les développeurs pour des billes. Un développeur SAIT installer son environnement de développement et les bibliothèques dont il a besoin.
[^] # Re: LWJGL
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Il y a pire, puisqu'il faut aussi :
- un OS qui fait plusieurs Go.
- un PC avec écran, clavier et même une souris!
- un logement avec de l'électricité.
Bref c'est vraiment nul de ne pas pouvoir lancer une applet à poil dans la forêt!
Le développeur oui (et encore les problèmes d'installation occupent plusieurs pages du forum de LWJGL), le joueur non. Il faut donc passer du temps à packager ces bibliothèques et ce n'est pas une partie de plaisir, car comme c'est un mix entre des bibliothèques Java et des bibliothèques natives, c'est assez galère.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: LWJGL
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 5.
Dans la forêt ? mais il faudrait alors des arbres !...
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: LWJGL
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: LWJGL
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -2.
Le rapport est « amas / un » et est valide pour tout « un » non nul.
[^] # Re: LWJGL
Posté par shinobufan (site web personnel) . Évalué à 1.
[^] # Re: LWJGL
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: LWJGL
Posté par kowalsky . Évalué à 4.
====> [ ]
[^] # Re: LWJGL
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Performances
Posté par ʭ ☯ . Évalué à 1.
Lequel fonctionne le plus vite sur une vieille machine? Quelle empreinte mémoire?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Performances
Posté par Mehdi Yousfi-Monod (site web personnel) . Évalué à 2.
Nuncabola est davantage fluide, c'est justement sa raison d'exister.
Par contre je n'ai pas de vieille machine sous la main.
Pour l'empreinte mémoire, je ne suis pas très familier avec ça, j'ai trouvé sur un message de forum ici que gcore faisait l'affaire, mais voilà les valeurs :
Nuncabola (processus java) : 1437 Mo !
Neverball : 114 Mo
[^] # Re: Performances
Posté par Mimoza . Évalué à 1.
Neverball : 114 Mo
Autant le chiffre de Neverball me parait cohérant, mais celui de Nuncabola me parait un poil surestimer quand même ...
Sinon je m'en vais essayer de jeu Java dès ce soir ^_^
[^] # Re: Performances
Posté par BAud (site web personnel) . Évalué à 3.
il s'agit de mémoire virtuelle.
Au lancement, la mémoire utilisée est d'environ 100 Mo, 132 après un jeu.
En revanche, ce qui est un peu plus gênant, c'est les 100% d'un core pris :/ (bon j'en ai deux) et, ce, en permancence...
Pour le lancer, ce serait pas mal d'avoir un nuncola.sh contenant :
java -XX:+UseConcMarkSweepGC -jar nuncabola.jar
Cela fonctionne correctement sur Mandriva Linux 2010.0 en x86_64 avec
java-1.6.0-openjdk-1.6.0.0-0.20.b16.11mdv2010.0
(téléchargement du .zip binaire+data puis unzip et zou lancement avec la commande ci-dessus).
[^] # Re: Performances
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Performances
Posté par zerkman (site web personnel) . Évalué à 5.
[^] # Re: Performances
Posté par zyphos . Évalué à 5.
[^] # Re: Performances
Posté par Mr Kapouik (site web personnel) . Évalué à 3.
[^] # Re: Performances
Posté par tallion . Évalué à 4.
Je ne dis pas que les micro benchmark ne sont pas intéressants mais qu'il ne faut pas leur donner plus d'importance qu'ils en ont: la VM est complexe, lente à démarrer, le garbage collector est peu prédictible, le JIT a parfois de très bonnes optimisations... Le mieux est de prendre les projets dans leur globalité en vérifiant bien que les deux avaient le même but (performances ,maintenance, etc...)
Conclusion:Le bon outil pour le bon problème, et parfois C/C++/java peuvent tous être viable.
PS: un petit lien de bench qui date maintenant http://marc.info/?l=tomcat-user&m=106036177509367&w=(...)
[^] # Re: Performances
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...)
Et la mise en garde qui va bien: ce ne sont que des benchmarks, ils ne sont pas forcément représentatifs de l'usage réel, etc etc (mais je trouve cela tout de même assez intéressant, même si plein d'autres facteurs entrent en compte)
Mathias
[^] # Re: Performances
Posté par Mehdi Yousfi-Monod (site web personnel) . Évalué à 5.
Par ailleurs, le problème de fluidité de Neverball n'est pas lié au langage mais juste à l'implémentation du moteur physique.
Dans la version 1.4.0, il n'y avait pas ce problème, cependant le comportement de la balle n'était pas assez constant d'une machine à une autre, ce qui pouvait poser des problèmes pour la compétition : un film (replay) enregistré sur une machine pouvait produire un résultat sensiblement différent sur une autre. Par exemple, si le joueur attrape une pièce en la frôlant, elle pouvait ne pas être prise sur une autre machine (pas cool).
De plus, cet ancien moteur pouvait causer une différence de quelques centièmes de secondes sur un même parcours. Ceci a été observé plusieurs fois sur des niveaux très basiques où la trajectoire optimale est la ligne droite vers la sortie. Les meilleurs performances se battent souvent au centième de seconde...
La correction du moteur a consisté à le rendre déterministe, càd qu'il est maintenant censé produire toujours le même résultat pour une même séquence de contrôle en entrée. Techniquement il a fallu rendre constant l'intervalle de temps entre 2 états internes du moteur, plutôt que dépendant des performances de la machine.
Au niveau réalisme de la simulation on y perd un peu, mais au niveau gameplay / compétition, on y gagne.
Par contre, ça a causé le problème de fluidité. Elviz l'a résolu dans Nuncabola en procédant à des interpolations d'états du jeu. Par contre personne dans l'équipe n'a été capable d'en faire autant pour Neverball (limites dans les compétences en maths).
[^] # Re: Performances
Posté par swilmet . Évalué à 4.
[^] # Re: Performances
Posté par shinobufan (site web personnel) . Évalué à 6.
L'auteur a donc décidé de tout réécrire "from scratch" en imitant au plus près Neverball (mis à part l'interpolation). Il a des affinités avec le Java et la programmation objet et ne souhaitait donc pas le faire en C, il ne faut pas chercher plus loin à ma connaissance.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Release early, release often
Posté par swilmet . Évalué à -3.
Il n'a pas lu la cathédrale et le bazar lui...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.