Problème: JDesktopPane + Skin importé

Bonjour,

J'ai une application java avec un personnage que je déplace dans un JPanel dans une JFrame. Tout se passe bien, 0% de l'UC utilisée

1er Problème:
Lorsque j'importe un thème en utilisant en même temps un JDesktopPane (implémenté d'un JPanel et de 2 JInternalFrame translucides), ça utilise vers les 20% de mon UC soit environ 2.0GHz (je dispose d'un Q6600). Ce n'est pas le cas si j'enlève le thème ou si j'enlève le JDesktopPane en gardant le JPanel.

2e Problème:
De plus, je suis obligé d'utiliser la méthode setDragMode(JDesktopPane.OUTLINE_DRAG_MODE) sinon, lorsque mon personnage se déplace et que je bouge au même moment une JInternalFrame, sa vitesse se multiplie et il s'arrête plus loin que l'endroit où je clique.
Il s'arrête sans problème au point voulu en temps normal.

Ce déplacement est conçu de la façon suivante:
Lorsque je clique avec la souris, je détermine de combien en x et en y mon personnage, centré sur l'écran, doit se déplacer a chaque boucle du thread.
On a donc une vitesse de déplacement régie par le sleep du thread: cause du problème?
Ce thread a un sleep de 40 ms.
Ce calcul s'accompagne de 2 booléennes pour déterminer si le personnage va en haut ou en bas, à gauche ou à droite. Ainsi, lorsqu'il arrive au point où j'ai cliqué (MousePressed ou MouseDragged en fait), il s'arrête.

3eme problème:
Sous vista, lorsque j'ai le thème vista (par défaut), si je place ma JFrame de sorte qu'elle ait des pixels derrière le boutons "démarrer" qui est rond et qui dépasse de la barre, mon jeu se met à prendre dans les 15% de l'UC et le jeu rame. Dès que je monte la JFrame en dehors de ce bouton, l'UC se remet à 0%.

Merci de vos réponses et de votre temps passé à lire mon problème.

Sans code ou demo difficile de repondre plus en precisement.

1) Generalement le JDesktopPane a toujours ete un trou au niveau performance (d'ou les flags pour changer l'affichage quand on deplace une JInternalFrame).

2) Etrange, il semble que malgre le fait que tu utilises une Thread separee une partie de ton mouvement soit encore base sur des evenements de repeinture. Verifie bien ton code.

3) Quelques astuces d'optimisation :

- Il te faut optimiser ton rendu en tenant compte de la zone de clip du Graphics passe en paramettre de paint() ou paintComponent() et ce pour eviter de peindre des trucs inutiles.

- En contrepartie quand tu demandes un reaffichage il te faut appeler la variante de repaint() qui prend en compte une zone definie. Par exemple dans ton cas tu dois, a chaque pas de la Thread appeler repaint() une fois sur la position actuelle du perso et une fois sur la position suivante. Quand tu es dans l'EDT tu peux faire deux appels separes a repaint() et le repaint manager fera l'union des deux zones au moment du reaffichage (puisque dans l'EDT, il n'y a pas de reaffichage au moment ou tu appelles repaint() sauf si tu appelles repaintImmediatly() - ce que generalement il ne faut pas faire). Or bien sur ceci n'est pas garanti dans une Thread autre, donc : stocke la position du perso (toute la zone couverte), deplace-le, fait l'union de l'ancienne et de la nouvelle zone puis appelle repaint().

- Utilise des BufferedImage compatibles avec l'affichage que tu creeras grace a la classe GraphicsConfiguration. Cela permet d'obtenir un bon degree d'acceleration video.

- As-tu essayer de tester ton projet sur la derniere version en date de la beta de Java 1.6.10_update10 ? Le support de l'acceleration 2D est sense etre meilleur dans les dernieres versions (evidement comme c'est une beta, des bugs peuvent survenir cependant).

Avant tout merci pour ta réponse.

Citation:

---

Envoyé par bouye

1) Generalement le JDesktopPane a toujours ete un trou au niveau performance (d'ou les flags pour changer l'affichage quand on deplace une JInternalFrame).

---

Oui mais sans thème ajouté, l'UC n'est utilisé qu'a 3% (avec JInternalFrame translucide) et avec thème 15%.
Voici le code pour l'implantation du thème, ( librairie ) :

Code:

---

1 2 3 4

Skin theSkinToUse = SkinLookAndFeel.loadThemePack("themepack.zip"); SkinLookAndFeel.setSkin(theSkinToUse); UIManager.setLookAndFeel(new SkinLookAndFeel());

---

Y a-t-il un autre composant pouvant intégrer des JInternalFrame?

Citation:

---

Envoyé par bouye

2) Etrange, il semble que malgre le fait que tu utilises une Thread separee une partie de ton mouvement soit encore base sur des evenements de repeinture. Verifie bien ton code.

---

Effectivement une partie des calculs étaient effectué dans paintComponent :oops: Merci .

Citation:

---

Envoyé par bouye

3) Quelques astuces d'optimisation :

- Il te faut optimiser ton rendu en tenant compte de la zone de clip du Graphics passe en paramettre de paint() ou paintComponent() et ce pour eviter de peindre des trucs inutiles.


- En contrepartie quand tu demandes un reaffichage il te faut appeler la variante de repaint() qui prend en compte une zone definie. Par exemple dans ton cas tu dois, a chaque pas de la Thread appeler repaint() une fois sur la position actuelle du perso et une fois sur la position suivante. Quand tu es dans l'EDT tu peux faire deux appels separes a repaint() et le repaint manager fera l'union des deux zones au moment du reaffichage (puisque dans l'EDT, il n'y a pas de reaffichage au moment ou tu appelles repaint() sauf si tu appelles repaintImmediatly() - ce que generalement il ne faut pas faire). Or bien sur ceci n'est pas garanti dans une Thread autre, donc : stocke la position du perso (toute la zone couverte), deplace-le, fait l'union de l'ancienne et de la nouvelle zone puis appelle repaint().

---

J'ai essayé d'appliquer ce que tu as dis voici le code obtenu ( je n'ai pas bien saisie la fin ) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

protected void paintComponent (Graphics g) { super.paintComponent(g) ; g.clipRect(0, 0, dimEcran.width, dimEcran.height); g.drawImage(imageFond,(int)xPerso, (int)yPerso, null); g.drawImage(imageInnaccessible,(int)xPerso, (int)yPerso, null); g.drawImage(Personnage.getImage(), (dimEcran.width/2)-Personnage.getIconWidth()/2, ((dimEcran.height-28)/2)-Personnage.getIconHeight()+20, null); g.drawImage(imageDerniereCouche,(int)xPerso, (int)yPerso, null); g.dispose(); } //Dans la thread : regardeSiZoneAccessible(); /* Regarde les couleurs de l'image 'imageInnaccessible' par rapport à la position du personnage et si il y a de la couleur alors le déplacement est stoppé */ repaint(0,0,dimEcran.width,dimEcran.height); xPerso += dx; yPerso += dy;

---

Néanmoins il n'y a pas de diminution de l'UC utilisé ( mais surement de la carte graphique ) .

Citation:

---

Envoyé par bouye

- Utilise des BufferedImage compatibles avec l'affichage que tu creeras grace a la classe GraphicsConfiguration. Cela permet d'obtenir un bon degree d'acceleration video.

---

Je vais aller faire des recherches sur cette classe.

Citation:

---

Envoyé par bouye

- As-tu essayer de tester ton projet sur la derniere version en date de la beta de Java 1.6.10_update10 ? Le support de l'acceleration 2D est sense etre meilleur dans les dernieres versions (evidement comme c'est une beta, des bugs peuvent survenir cependant).

---

Je vais l'essayer.

J'ai remarqué qu'en n'ajoutant pas les JInternalFrame au JDesktop ( donc un JDesktop supportant seulement un JPanel ) l'UC était diminué.
Rendre les JInternalFrame translucide pourrait-il en être la cause?

Non, quand tu es dans paintComponent(), le Graphics a deja un clip qui lui a ete fourni par le RepaintManager en fonction, entre autre des appels que tu as effectue a repaint().
Tu dois donc recuperer cette forme (via getClip()) et verifier si ce que tu dois peindre est bien dans la zone a reafficher (si c'est dedans ou si ca l'intersecte). Si c'est le cas, tu redessines, sinon tu ne redessines pas.

Et c'est la tout l'interret de ne demander un repaint() que sur une portion specifique de l'ecran : ne redessiner que ce qui se trouve a cet endoit.

Ainsi plutot que d'appeler repaint(0,0,dimEcran.width,dimEcran.height); ce qui semble correspondre a tout ton ecran, concentre-toi uniquement sur la zone qui a besoin d'etre redessinnee.

Citation:

---

Envoyé par bouye

Tu dois donc recuperer cette forme (via getClip()) et verifier si ce que tu dois peindre est bien dans la zone a reafficher (si c'est dedans ou si ca l'intersecte). Si c'est le cas, tu redessines, sinon tu ne redessines pas.

---

Je suis désolé mais je ne vois vraiment pas comment faire :oops:

Récupérer le clip du Graphics de la méthode paintComponent(), ok
Mais vérifier si ce que je dois peindre est bien dans la zone à reafficher je vois pas.

En simplifier, j'utilise un Thread qui fait un

Code:

---

repaint();

---

et une méthode paint(Graphics) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public void paint (Graphics g1) { Graphics2D g =(Graphics2D) g1; super.paintComponent(g) ;   if((int)xPerso!=0 | (int)yPerso!=0) g.translate((int)xPerso,(int) yPerso);   g.drawImage(fond,0, 0, this); g.translate(-(int)xPerso,-(int) yPerso);   g.drawImage(myImagePerso[currentMyImagePerso].getImage(), (dimEcran.width/2)-myImagePerso[0].getIconWidth()/2, ((dimEcran.height-28)/2)-myImagePerso[0].getIconHeight()+20, null);   g.drawImage(couche3,(int)xPerso, (int)yPerso, this); }

---

Tu parle aussi d'utiliser des bufferedImages grâce à la classe GraphicsConfiguration, cette méthode suffit-elle?

Code:

---

1 2 3 4 5 6 7 8 9

public BufferedImage toBufferedImage(Image image) { image = new ImageIcon(image).getImage(); BufferedImage bufferedImage = new BufferedImage(image.getWidth(null),image.getHeight(null),BufferedImage.TYPE_BYTE_BINARY ); Graphics g = bufferedImage.createGraphics(); g.drawImage(image,0,0,null); g.dispose(); return bufferedImage; }

---

Voilà, merci pour ta patience.

1) getClip() retourne une Shape, or tu connais et la position de ton perso et sa boite englobante (x, y, x+width, y+height) donc tu peux tres bien appeller les methode contains() et intersects() de l'interface Shape. CQFD.

Cela peut sembler donner lieu a des calculs plus complexes mais en fait tu gagnes enormement plus en optimisation ainsi qu'en dessinant tout le temps tout alors que durant certains repaint, si tu as fait les bons appels, seule une toute partie de l'affichage est a changer/redessiner.

2) non car une BufferedImage cree ainsi peut ne pas etre dans le format interne de la carte video. Donc au moment de la composition sur l'ecran, cette image sera convertie en un format compatible ce qui ralentira l'affichage (conversion qui sera effectuee a chaque reaffichage). Tu peux gagner enormement en performances en utilisant des BufferedImage compatibles des le depart, celles crees par GraphicsConfiguration.createCompatibleImage(...).

Merci pour la réponse.
Donc pour l'utilisation du GraphicsConfiguration à la place d'un :

Code:

---

1 2	Toolkit toolkit = java.awt.Toolkit.getDefaultToolkit(); Image fond = toolkit.getImage("monImage.png");

---

on a :

Code:

---

1 2 3 4

BufferedImage bufImage = ImageIO.read(new File(""monImage.png"")); GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration(); BufferedImage fond= gc.createCompatibleImage(bufImage.getWidth(), bufImage.getHeight(), Transparency.TRANSLUCENT); fond.getGraphics().drawImage(bufImage, 0, 0, null);

---

soit seulement une modification de la construction des images, mais au niveau du paintComponent(), aucun chagement, toujours un :

Code:

---

g.drawImage(fond,0, 0, this);

---

c'est bien ça?


Pour ce qui est de l'utilisation des Clips, j'aimerais avant donner quelques précisions sur la méthode utilisé :
pour faire déplacer le personnage je déplace l'image de fond mais je dessine aussi les déplacements des autres 'personnages'

Donc pour limiter les repaint() à une zone comme tu l'a suggéré, ( sans vraiment utiliser de getClip() et Shape :oops: ) voilà comment je procède dans mon Thread :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public void run () { //...   if ( dx! =0 | dy !=0) repaint(); /* si il y a un déplacement je repaint tout puisque tout le fond doit bouger */ else if (deplacementOtherPersoChange) repaint(zone où se situe les autres personnages); /* si les positions des autres personnages ont changé */   try {Thread.sleep(40);} catch (InterruptedException e) {} }

---

C'est tout aussi efficace non?

Pour la creation des images oui c'est ca.

Ah donc c'est tout ton fond qui scrolle quand le perso controlle se deplace (lui restant au centre de l'ecran*) ? Dans ce cas pour un repaint() optimise rapide a mettre en place il n'y a pas 36 solutions : c'est toute la zone modifiee qui doit etre redessinnee. Cependant de maniere plus avancee, il existe d'autres possibilite d'optimisation nottament avec la methode copyArea() de la classe Graphics qui permet un decallage du fond en le recopiant ailleurs (c'est plus rapide que de redessiner l'image entiere) et uniquement dessiner le fond en utilisant l'image source dans les nouvelles zones apparues a l'ecran. Bien sur il faut faire un traitement un peu plus attentif autour du perso lui-meme pour eviter qu'il n'apparaisse en double.

Pièce jointe 37404

Note : la fleche noire represente le vecteur deplacement du perso dans la premiere image. Dans les images 2 et 3 elle represente la norme de ce deplacement. Sur la derniere image on a a la fois redessinne le perso et le rocher qui est devant lui.

*Que se passe-t-il lorsque ton perso arrive en bords de zone (ex : on est arrive a l'extreme droite de la carte, impossible de scroller plus a droite) ? Est-ce qu'a l'instar de nombreux jeux 2D console, le fond se fige/arrete de scroller et c'est le perso qui se deplace a la place ? Dans ce cas un repaint() sur zone plus restreinte est possible.

Revenu sur les autres : si ton personnage est immobile, les autres peuvent-il se deplacer (ou sont-ils animes de quelconque maniere ?) ou le fond ou le decors a-t-il des animations ? Dans ce cas tu peux essayer d'optimiser juste en les repeignant eux.

De toute maniere tu vas etre ammene a un moment ou a un autre a gerer les boites englobantes nottament si tu veux faire de la collision de sprites. Cela permet de faire vite des tests de colision avant de passer sur des tests plus pousses (via un masque nottament) quand les boites en englobantes de 2D sprites se rencontrent.

Ah oui l'optimisation de base : si rien n'a change, ca ne sert a rien de redessiner (cf ta boucle). Cependant tu peux vouloir faire un redessin complet de temps a autre (mais sur un plus grand pas de temps), histoire d'avoir un key frame complet (un pleu a la maniere de la lecture de flux MPEG).

Citation:

---

Envoyé par bouye

Ah donc c'est tout ton fond qui scrolle quand le perso controlle se deplace (lui restant au centre de l'ecran*) ?

---

Oui. Voila un screen type pour que tu puisse voir de quoi il s'agit. Le personnage reste toujours centré à l'écran avec une vue en diagonale mais pas de face.

Quand le personnage arrive aux bouts de la carte il sera bloqué par un objet et il y aura un décor après cette objet ( sur le screen c'est en blanc).
Pour bloquer le personnage lorsqu'il arrive dans un objet, il y a une thread qui regarde la position du personnage et stop le déplacement si la méthode getRGB() équivaux à -1 sur le masque.

Je ne vois pas vraiment d'autres façon d'optimiser le rendu, la méthode copyArea() lors d'un déplacement n'est pas vraiment utile ici vu que tout le fond bouge.

Si le personnage est immobile les autres peuvent se déplacer quand même c'est pour ça que je dois repaint certaines zones si les autres coordonnées sont différentes.

Peut-ont penser à l'utilisation d'un DoubleBufferingHardware ou DoubleBufferingSoftware pour un jeux 2D?

:D, ca me rappelle Ultima Online.

"Normalement", si ; la method copyArea() fonctionnerait bien puisque justement c'est tout le fond qui se deplace (voir image que j'ai donne precedement). Cependant, il faut bien sur faire des tests de performance dans divers scenario pour voir quelle est la meilleure approche : evidement si au final tu dois remettre a jour complement l'ecran (ex: trop de perso ont besoin d'etre redessinnes car ils ont change leur animation, etc...), la copie initiale peut sembler inutile.

L'utilisation de BufferStrategy et de l'acceleration hardware est assez penible a mettre en place nottament car tu es restreint sur le type de composant que tu peux utiliser pour la manipuler. L'utilisation de VolatileImage n'est pas non-plus aisee. Generalement, tu ne devrais pas en avoir besoin (nottament si tu ne veux pas basculer en mode plein ecran). Mais apres on ne sait jamais, peut-etre t'orienteras-tu vers cette direction pour ton jeu.

Cote software tu peux tres bien faire un rendu offscreen dans une BufferedImage (compatible bien sur) et composer celle-ci, par contre cela mangera bien sur plus de memoire. De plus, cela ne te dispenses pas non-plus, de faire des optimisations sur les zones a repeindre tant sur l'image offscreen elle-meme que lors de sa composition a l'ecran.