Discussion :

[Dimitri_87]

Bonjour à tous,

Voilà, j'ai commencé un petit jeu de type Mario en Java.
J'arrive bien à faire bouger mon hero sur une image de fond mais les performances
ont l'air très pauvre pour la faible quantitée d'informations que j'affiche.
J'utilise le Java de base, donc avec des paint() pour le rafraichissement de l'écran. J'ai mit en oeuvre un Double Buffering Hardware pour améliorer les performances mais cela reste assez lent (saccades) au niveau des animations de déplacement de mon personnage (alors que pour l'instant il est tout seul à l'écran). Si je ne rafraichit pas la zone de jeux, la les animations sont beaucoup plus fluides.
Voilà, j'aimerais savoir si, même pour un simple petit Mario-like, il faudrait passer par un librairie de style JOGL ou LWJGL ??

Merci

[nouknouk]

salut,

1/ le principe est de ne pas réafficher l'ensemble de la fenêtre à chaque fois, mais plutôt ne redessiner que les parties qui ont changé (genre le perso à bougé => on réaffiche le décor là où il était avant ; on réaffiche le perso à sa nouvelle position). C'est le prinicpe générique des 'dirty rectangles' dont j'ai esquissé l'idée ici.

2/ Attention à la façon dont sont programmés les ré-affichages. Obtenir qu'une fonction soit exécutée très régulièrement, toutes les x millisecondes n'est pas si simple que ça. Par exemple un sleep(1) sur un thread donnera des résultats très variables, parfois très loin de la milliseconde escomptée, et très dépendant du système d'exploitation utilisé.

3/ il faut prendre en compte la vitesse de rafraichissement de l'écran: si ton écran est sur 60Hz (le classique des LCD ; 16.7ms entre deux images) et que ton programme boucle à 50Hz (toutes les 20ms) pour redessiner ton jeu, il y aura forcément un décalage qui variera périodiquement au cours du temps d'où une impression désagréable de saccade.

=> Tous ces problèmes font qu'il n'est pas trivial (même si ça reste évidemment possible) de faire des animations 2D fluides et performantes en Java. Le mieux est encore d'utiliser des librairies ou des frameworks spécialement prévus pour ça. Deux exemples:

- JavaFX.

- Pulpcore, que j'affectionne particulièrement pour sa légèreté, son efficacité et ses performances pour faire (uniquement) des applets en 2D, à l'image de ce que peut proposer Flash.

[luckyvae]

Ce n'est pas nécessaire de passer par openGL pour faire un petit mario-like.
Si ça saccade au stade que tu décris, c'est qu'il y a un soucis de conception.

Quel est ton schéma de boucle principal? Utilises-tu un FPS défini ou un FPS libre?

[Djakisback]

3/ il faut prendre en compte la vitesse de rafraichissement de l'écran: si ton écran est sur 60Hz (le classique des LCD ; 16.7ms entre deux images) et que ton programme boucle à 50Hz (toutes les 20ms) pour redessiner ton jeu, il y aura forcément un décalage qui variera périodiquement au cours du temps d'où une impression désagréable de saccade.

Nouknouk, tu pourrais préciser ce point ? il y a quelques temps j'ai développé un truc avec JOGL. J'avais des bonnes perfs, 500 cycles/s mais j'avais quand même une impression de non-fluidité que je n'arrivais pas à m'expliquer. (Je précise que je ne parle pas de l'effet "tracé de lignes" qu'on a quand on rend au-dessus du framerate de l'écran mais bien d'une espèce de lag/saccadements.)

[nouknouk]

Je parlais ici des soucis de synchronisation verticale (communément appelée vsync), donc j'imagine que c'est ce que tu appelles toi 'tracé de ligne'.

Pour ceux qui ne connaissent pas, c'est la fait que tout écran a une fréquence de rafraîchissement (typiquement f = 60Hz). Donc toutes les 1000/f millisecondes, le chipset graphique va lire la zone mémoire où l'ensemble des pixels sont stockés et les afficher à l'écran.
L'affichage ne changera pas jusqu'au prochain rafraîchissement, soit 1000/f millisecondes plus tard, même si les pixels ont été modifiés entre temps dans la zone mémoire.

Le souci typique avec cette méthode est lorsque l'écran est rafraîchi pendant qu'on redessine l'écran (en général de haut en bas). Dans ce cas, la partie haute de l'image est la nouvelle image en train d'être dessinnée ; la partie basse est l'ancienne qu'on n'a pas encore eu le temps de redessiner.
Pour un objet en mouvement, on se retrouve alors avec ce genre de chose:



La solution à ce souci est la synchronisation verticale: on se synchronise avec le moment où l'écran est rafraîchi pour être certain de ne pas être en train de redessiner l'image dans la zone mémoire pendant que l'image est rafraîchie à l'écran. Ceci n'est pas possible dans l'état actuel des choses avec Java "de base" (mais faisable avec une librairie genre JOGL qui propose un binding vers openGL qui lui a cette faculté).

Concernant ton souci, Djakisback, je pense que ça vient d'ailleurs ; peut-être ton code partait sur l'idée qu'entre deux images le temps écoulé était constant (ce qui est rarement le cas), plutôt qu'évaluer à chaque nouvelle itération le temps réellement écoulé depuis le dernier affichage. Ou alors tu évaluais effectivement le temps écoulé, mais avec une méthode peu précise ?

Quoi qu'il en soit, l'utilisation de JOGL change radicalement l'approche à adopter pour le développement du moteur d'affichage par rapport à un moteur de rendu 'software' (genre Java 2D, ...).

A noter: cet article (en Anglais) et les articles connexes qui se révèlent très instructif sur le sujet.

[Dimitri_87]

Voilà ma boucle principale,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public void run() {
 
        this.strategy = getBufferStrategy();
        ground = new Ground(getWidth(), getHeight());
        while(isVisible())
        {
            hero.move();  // Déplacement du joueur
 
            checkCollision(); // Vérifie les collisions
 
            paintWorld(); // Peint le nouveau monde
 
            try {
                Thread.sleep(45);
            } catch (InterruptedException ex) {
            }
        }
    }

Et voici ma méthode paintWorld :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public void paintWorld() {
 
        Graphics g = strategy.getDrawGraphics();
        // Dessine le décor
        g.drawImage(background, 0, 0, getWidth(), getHeight(), this);
        ground.paint(g); // Dessine le sol
        hero.paint(g); // Dessine joueur
        g.dispose();
        strategy.show(); // Affichage
    }

[nouknouk]

Voilà ma boucle principale [...]

Je vois deux sources potentielles de problèmes :

- le thread.sleep() a un comportement qui se rapproche du 'best effort'. Comprendre par là, que cette méthode ne garanti absolument pas que le thread se réveillera pile poil 45ms après le sleep. Ca peut très bien être 45ms, comme 47ms, etc... Ca peut même monter jusqu'à une quinzaine de ms supplémentaire (33% de plus !), voire plus en fonction du type d'OS et de la résolution de l'ordonnanceur. En y ajoutant les soucis de synchronisation avec le rafraîchissement de l'écran, on peut encore se décaler de 10 à 20ms supplémentaires.

- à chaque image tu redessines la totalité de l'image. Or un simple appel à g.drawImage(background, 0, 0, getWidth(), getHeight(), this); peut à lui seul flinguer les performances pour peu que la taille du composant soit relativement grande.

D'où l'obligation de passer par un mécanisme de "dirty rectangles" présenté ci-dessus.

[luckyvae]

le thread.sleep() a un comportement qui se rapproche du 'best effort'. Comprendre par là, que cette méthode ne garanti absolument pas que le thread se réveillera pile poil 45ms après le sleep. Ca peut très bien être 45ms, comme 47ms, etc... Ca peut même monter jusqu'à une quinzaine de ms supplémentaire (33% de plus !), voire plus en fonction du type d'OS et de la résolution de l'ordonnanceur. En y ajoutant les soucis de synchronisation avec le rafraîchissement de l'écran, on peut encore se décaler de 10 à 20ms supplémentaires.

En effet, en affinant ce passage tu pourras avoir un FPS plus constant. Pour ça, tu regardes combien le sleep dure, et si celui-ci fut trop court ou trop long, tu ajustes au temps suivant. De plus, tu dois regarder combien de temps tu met pour dessiner.

à chaque image tu redessines la totalité de l'image. Or un simple appel à g.drawImage(background, 0, 0, getWidth(), getHeight(), this); peut à lui seul flinguer les performances pour peu que la taille du composant soit relativement grande.

D'où l'obligation de passer par un mécanisme de "dirty rectangles" présenté ci-dessus.

Je ne penses pas que ce soit vraiment nécessaires ou que ce soit une priorité, enfin, tout dépend de la taille de ta fenêtre graphique...


Ce que je dirais moi, c'est d'abord faire en sorte d'avoir un FPS constant et alors, si tu as des ralentissements qui proviennent de l'affichage, essayer d'implémenter cette méthode.


Sinon, une autre méthode que tu peux faire, c'est choisir un FPS variable et tu gères ce degré de liberté...

[Sivrît]

D'où l'obligation de passer par un mécanisme de "dirty rectangles" présenté ci-dessus.

Ça ne va pas être problématique pour réaliser un scrolling ? Et c'est relativement complexe à mettre en place... est-ce qu'il ne vaut pas mieux passer directement à une solution OpenGL (ou autre) ?

[franck06]

Bonjour à tous,

Voilà, j'ai commencé un petit jeu de type Mario en Java.
J'arrive bien à faire bouger mon hero sur une image de fond mais les performances
ont l'air très pauvre pour la faible quantitée d'informations que j'affiche.
J'utilise le Java de base, donc avec des paint() pour le rafraichissement de l'écran. J'ai mit en oeuvre un Double Buffering Hardware pour améliorer les performances mais cela reste assez lent (saccades) au niveau des animations de déplacement de mon personnage (alors que pour l'instant il est tout seul à l'écran). Si je ne rafraichit pas la zone de jeux, la les animations sont beaucoup plus fluides.
Voilà, j'aimerais savoir si, même pour un simple petit Mario-like, il faudrait passer par un librairie de style JOGL ou LWJGL ??

Merci

Salut,

comme nouknouk que je croise souvent sur cette partie du forum, dont les precisions, explications et conseils sont au top , j'utilise aussi Pulpcore
qui est vraiment tres leger, facile a prendre en main et que je te conseille aussi tres fortement. Pour le background faudra gere toi meme le scrolling (mais y'a un tutoriel tres simple la dessus), et pour les sprites, c'est vraiment tres simple a utiliser.
Niveau perf, c'est du solide, t'as pas d'inquietudes a avoir sur un mario-like ...

bonne chance, screenshotes un peu qu'on suive un peu, j'aime bien suivre les projets
@+

[nouknouk]

Ça ne va pas être problématique pour réaliser un scrolling ?

Le cas du scrolling est un cas particulier, en effet: puisque l'ensemble du contenu est modifié, l'ensemble du jeu va être effectivement redessinée. Ce cas représente le cas limite, où le 'dirty rectangle' généré correspond à l'ensemble de la surface affichée, et donc le rendu équivaut à un système sans dirty rectangle.

Et c'est relativement complexe à mettre en place...

La notion de dirty rectangle n'est pas si complexe que ça: l'idée de base est que la boucle de rendu divisée en plusieurs étapes:

1/ J'estime le temps écoulé depuis la dernière image rendue. J'obtiens une valeur (Tx millisecondes) qui être utilisée pour les déplacements (deltaX = VitesseX * Tx) et les enchaînements d'images pour les sprites animés.

2/ j'applique la logique du jeu pour les déplacements et les animations

2.1/ Je calcule les nouvelles positions de chaque sprite en mouvement, en fonction de Tx ; pour chaque sprite qui a bougé, j'ajoute dans la liste des dirty rectangles leur position de départ ET d'arrivée.

2.2/ pour chaque sprite animé qui voit son image changer, j'ajoute à la liste des dirty rectangles le rectangle correspondant au sprite.

2.3/ (optionnel) je consolide la liste des dirty rectangles, par exemple en fusionnant les rectangles qui ont suffisamment de surface en commun.

3/ pour chaque dirty rectangle de la liste, je réaffiche tout ce qu'il contient (fond, sprites, ...), en prenant soin d'utiliser un mécanisme de clipping à la fois pour optimiser l'affichage (ne pas perdre de temps à rendre une partie de l'image qui ne change pas) et ne pas 'déborder' à l'extérieur du dirty rectangle

Bref, rien de très complexe à mettre en oeuvre finalement. Et c'est sans conteste et de loin la meilleure façon d'optimiser le rendu.

Le code source du framework pulpcore peut également servir de large source d'inspiration pour mettre en place ce genre de système.

est-ce qu'il ne vaut pas mieux passer directement à une solution OpenGL (ou autre)

Une solution basée sur OpenGL est radicalement différente. Elle a l'énorme avantage d'utiliser les accélérations hardware du circuit graphique, et permet d'obtenir des performances sans comparaison possible avec un rendu software.
Mais elle a également ses inconvénients, genre des soucis d'incompatibilité, de portabilité (car ne faisant pas partie du package 'de base' de J2SE) et l'impossibilité par exemple de l'intégrer dans une applet non signée.

Pas de réponse définitive, donc. Au concepteur de voir quelle est la solution qui convient le mieux par rapport à son contexte et ses objectifs.

j'utilise aussi Pulpcore qui est vraiment tres leger, facile a prendre en main et que je te conseille aussi tres fortement.

Pulpcore a beaucoup de points forts, mais il ne faut pas oublier de mentionner ses 'limites' pour rester objectif : pulpcore est (en l'état) uniquement destiné à produire des applets embarquées dans une page web ; le développement d'applications couramment appelées 'desktop' ou 'stand alone' n'est pas supporté pour le moment, même si des travaux sont en cours pour rendre tout ça possible (*).

(*) j'avais d'ailleurs moi-même fait un premier 'proof of concept' sur le portage en appli desktop qui avait révélé que le travail nécessaire pour y parvenir était loin d'être gigantesque. Cf. le groupe de discussion de pulpcore.

[Dimitri_87]

Ouaww, merci pour toutes ces réponses.
Je suis un peu absent car en examen, désolé.
Pour les screenshots, je n'ose pas les mettre car les sprites viennent de "Secret Maryo Chronicles" .
J'ai bien comprit le système de "dirty rectangle", mais qui du background que je dessine à chaque fois pour le moment. Il faut que j'arrive à me déplacer dans l'image pour redessiner chaque partie modifiée.

[franck06]

Pulpcore a beaucoup de points forts, mais il ne faut pas oublier de mentionner ses 'limites' pour rester objectif : pulpcore est (en l'état) uniquement destiné à produire des applets embarquées dans une page web ; le développement d'applications couramment appelées 'desktop' ou 'stand alone' n'est pas supporté pour le moment, même si des travaux sont en cours pour rendre tout ça possible (*).

(*) j'avais d'ailleurs moi-même fait un premier 'proof of concept' sur le portage en appli desktop qui avait révélé que le travail nécessaire pour y parvenir était loin d'être gigantesque. Cf. le groupe de discussion de pulpcore.

ouep c'est sur que c'est destiné a l'applet donc page web obligatoire

si ca lui pose vraiment probleme, avant ca pour du standalone, j'avais testé SLICK (basé sur LWJGL) et franchement j'avais trouvé ca super aussi, et j'etais rapidement arrivé a quelque chose de sympa
bonne communauté, des exemples de jeu, des tutorieux, c'est du lourd aussi

pour la 2d, oublie pas aussi que tu peux aussi utiliser une librairie comme Phys2d si tu veux mettre un peu de physique derriere

[merill]

Ton code ne devrait pas ramer, pour peu que tu evite de faire une erreur: faire un "scale".
En effet, la fonction drawimage que tu utilise risque de generer un scale de ton image, ce qui flingue complètement les perf.
Si tu as besoin de faire ce "scale", fait-le une fois pour toute puis dessine l'image "scalé".
fait vraiment attention aux paramètres que tu passe a ta fonction de dessin. Utilise plutôt drawImage(image, x, y, observer) dont on est sur qu'il en fait jamais de "scale". Les autres marchent aussi, je les utilise aussi mais il faut vraiment faire gaffes aux paramètres, par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
drawImage(image, x1,y1, x1+width-1, y1+height-1, x2,y2, x2+width-1, y2+height-1, observer)

marche car il ne redimensionne rien, il prend juste une partie de la première image et la plaque dans le graphics. Pas de scale, c'est donc optimisé hardware.

ps: par "scale" j'entends un redimensionnement de l'image à la maniere de "étirer" de paint

[Dimitri_87]

Bonsoir à tous,

Voilà après toutes les infos que vous m'avez données, j'ai obtenu une bonne fluidité. J'ai implémenté la technique de "dirty rectangle" comme conseillé plus haut.
Je poste un petit screenshot. Attention, je le re-précise, les sprites viennent du jeu Secret Maryo Chronicles, on ne sait jamais .



A++

[nouknouk]

sympa le feedback

On a hâte de pouvoir tester !