[Exception]Double buffering & NullPointerException

J'avais posté à propos d'un problème de scrolling, ça été résolu avec le double buffering. c'était ici :
http://www.developpez.net/forums/viewtopic.php?t=218987

Mais depuis l'appel à update(g) provoque une NullPointerException, qqs secondes après le démarrage du programme (qui affiche juste un écran).

J'avais cette erreur qd je faisais repaint() pour rien, mais même en les enlevant, ça fait l'erreur (qui ne stoppe pas le prog).

J'ai fait comme ça :

Dans la classe Jeu :

Code:

---

1 2 3

private Image backbuffer = null; private Graphics backg = null;

---

Dans le construteur Jeu() :

Code:

---

1 2 3 4 5 6

backbuffer = createImage(largeur, hauteur); backg = backbuffer.getGraphics(); backg.setColor(Color.black);   afficheEcranTitre(backg);

---

Dans afficheEcranTitre(backg), je dessine dans backg.
Et à la fin je fais un repaint();

Et c'est la-dedans que l'exception apparaît :

Code:

---

1 2 3 4 5 6 7 8

public void paint(Graphics g) { update(g); // bug après qqs secondes }   public void update(Graphics g) { g.drawImage(backbuffer, 0, 0, this); }

---

L'exception complète :

Code:

---

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

java.lang.NullPointerException at sun.java2d.pipe.DrawImage.copyImage(Unknown Source) at sun.java2d.pipe.DrawImage.copyImage(Unknown Source) at sun.java2d.SunGraphics2D.drawImage(Unknown Source) at sun.java2d.SunGraphics2D.drawImage(Unknown Source) at Jeu.update(Jeu.java:146) at Jeu.paint(Jeu.java:139) at sun.awt.RepaintArea.paint(Unknown Source) at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)

---

merci

C'est ton contexte graphique bakg qui génère un NullPointerException parce qu'il n'existe pas !

:arrow: Il faut utiliser la méthode createGraphics(); :

Code:

---

1 2 3 4 5 6 7 8

/**  * Crée le contexte graphique  */ private void initializeBackBuffer(){ backBuffer = new BufferedImage(this.FRAME_WIDTH,this.FRAME_HEIGHT,BufferedImage.TYPE_INT_ARGB); backg = backBuffer.createGraphics(); }

---

A noter que dans cet exemple, FRAME_WIDTH et FRAME_HEIGHT ne sont pas des constantes prédéfinies...

Code:

---

1 2 3

public void paint(Graphics g) { update(g); // bug après qqs secondes }

---

deja on appelle jamais la méthode update() directement, c'est java qui s'en charge lorsqu'on appelle repaint()

pour le reste la solution a été posté précédemment par Pascmar :wink:

Merci !

J'ai changé ça :

Code:

---

1 2 3 4

private Image backBuffer = null; backBuffer = createImage(largeur, hauteur); backg = backBuffer.getGraphics();

---

En ça :

Code:

---

1 2 3 4

private BufferedImage backBuffer = null; backBuffer = new BufferedImage(largeur, hauteur, BufferedImage.TYPE_INT_ARGB); backg = backBuffer.createGraphics();

---

La seule chose qui a changé c'est la fluidité : c'est bcp moins bien avec une BufferedImage... Donc j'ai remis une Image.

Mais j'ai supprimé la redéfinition de paint() qui appelle update(g) : là ça marche ! Il n'y a plus d'erreur, ouf !


Au fait, j'ai pas très bien compris le rôle de paint, repaint et update... Quand on ne les redéfinit pas, elles font quoi ?

c'est moins bien avec ta bufferedImage car tu l'as mis en ARGB hors Java ne met pas directement d'accelération sur une bufferedImage avec une couche Alpha
fais la passer en transparency.OPAQUE tu vas voir la différence :P
carrément mieux qu'avec une image :D

si tu définis paint() tu peux afficher ce que tu veux sur ton objet
si tu définis update() tu peux gerer le nettoyer de ton objet
la méthode repaint() est comprise dans java pour faire passer les graphismes par pipelines

l'affichage d'un objet se déroule ainsi:

paint() // initialisation de la partie graphique de ton objet
repaint() // appelle de la mise a jour de l'affichage
repaint()
repaint()
etc.......

repaint() appelle => update()
ce qui donne réellement a l'écran:
paint()
update()
update()
update()
etc......

heureusement update() est redéfinissable et on peut rappeler paint() pour limiter le clignottement:

Code:

---

1 2 3 4

public void update(Graphics g) { paint( g ); }

---

ce qui fait:
repaint() appelle => update() -> paint()
ce qui donne réellement à l'écran:
paint()
update()
paint()
update()
paint()
etc......

voila j'espere avoir été assez simple car c'est pas la partie la plus facile de java a comprendre étant donné que c'est implicite à chaque objet graphique.

Ahhhhhhhh c'était donc ça le "A" de ARGB !! thanx :D

J'ai remis la BufferedImage, mais en RGB. En effet, c'est mieux ! Peut-être même mieux qu'une Image, mais là c'est à cause de mon code que je ne voit pas trop la différence : je redessine à chaque keyPressed, je pense plutôt lancer le scrolling sur un keyPressed et l'arrêter sur un keyReleased, comme ça je ne dépendrai plus de la vitesse max du clavier qd on laisse appuyée une touche. Enfin, je pense, je dois essayer !

Petit à petit, ça avance... :)

Merci aussi pour tes explications sur paint et cie, je vais relire ça, faut le temps de digérer ! 8O lol

je ne sais pas exactement l'usage que tu va faire de ton code, mais quoi qu'il en soit, il est toujours plus avantageux d'utiliser une BufferedImage pour ce genre de problèmes car son contenu peut provenir de plusieurs threads chargés de dessiner différents éléments à intervalles réguliers à l'aide de backg passé en paramètre par exemple => le contenu de l'image doit être modifiable => BufferedImage...

Je veux faire un jeu de rôle (plein écran).

Merci du conseil. Justement, ça me fait penser à une autre question... Si je veux faire une scène nocturne à partir d'images de jour, c'est mieux de modifier à chaque frame la BufferedImage (baisse de luminosité + filtre bleu foncé) ou bien de mettre carrément par dessus une image bleue très foncée en transparence ?

bonne question, je sais pas vraiment, essaies les deux options et regardes laquelle est la plus rapide. Mais la manière la plus juste conceptuellement et peut-être de créer un nouveau thread de dessin qui va se charger de dessiner par dessus un rectangle bleu en transparence variable. Cependant attention, dès que tu manies plusieurs threads qui ont accès aux mêmes données en même temps, il faut être sûr de l'ordre dans lequel les actions se produisent : si le thread "de nuit" dessine son rectangle avant celui qui dessine le reste de l'image, on n'y voit rien. Les méthodes sychronisées sont plus lentes, il est peut-être judicieux de gérer manuellement l'état du thread de dessin (dessine - ne dessine pas) avec un boolean interne modifiable par la classe qui se charge de l'affichage final et qui donne la main au thread voulu au moment voulu...

Ok. Bon, avant de m'attaquer aux threads, je dois me documenter ! Je plongerai dans le code après...


En fait, mon projet est assez vieux, j'avais commencé fin 2001... Et jusqu'à qqs semaines, je le faisais en... JavaScript !!! lol ! :P (je ne savais faire que du html à mes débuts...) D'ailleurs j'ai été surpris d'aller aussi loin, ça ressemblait presque à un vrai jeu... Et là j'ai une révélation : il faut que je le fasse en Java ! Et je viens encore de trouver un énorme avantage à ça : plus besoin de découper mes lieux en plein de petites images ! Je viens de tester avec tout un village, une big image 1920*3136 pixels ! 8O Et le tout défile parfaitement à l'écran... impressionnant ! Je l'ai d'abord mis en gif : 1.75 Mo... Puis j'ai essayé le png : 993 Ko !! youpi !!! Et en plus, la qualité est meilleure, en gif je perdais des couleurs...

Question au passage : en gif, on est limité à 256 couleurs... En png, que je ne connais pas du tout, pas de limite ?? ce sont les couleurs exactes ?

Citation:

---

BufferedImage (baisse de luminosité + filtre bleu foncé) ou bien de mettre carrément par dessus une image bleue très foncée en transparence ?

---

tu affiches ta bufferedImage
tu passes en transparence style 0.8f
tu passes en couleur noire
tu mets un fillRect(x, x, x, x)

Citation:

---

une big image 1920*3136 pixels

---

j'serais curieux de voir le nombre de FPS

Citation:

---

J'ai remis la BufferedImage, mais en RGB. En effet, c'est mieux ! Peut-être même mieux qu'une Image

---

c'est normal beaucoup de programmeurs de jeu sur Java se plaignent que l'ajout de la couche Alpha des bufferedImage ne permet pu de bénéficier de l'accélération graphique
heureusement y'a des solus, les p'tits gars de Sun ont laissé ca:

Code:

---

1 2	System.setProperty("sun.java2d.translaccel", "true"); System.setProperty("sun.java2d.accthreshold", "0");

---

sur windows ca permet de passer par les pipelines de directX et sur linux, solaris de passer par ceux de DGA

Citation:

---

je redessine à chaque keyPressed, je pense plutôt lancer le scrolling sur un keyPressed et l'arrêter sur un keyReleased, comme ça je ne dépendrai plus de la vitesse max du clavier qd on laisse appuyée une touche

---

pas bonne idée, redessine en permanence à l'aide d'un timer(un Thread) qui rappelle tout l'temps ta fonction repaint()

si t'as d'autres questions, j'suis dans l'coin
bonne chance :wink:

En vrac, mon expérience dans le Java2D...:wink: ce fut une tentative de voir si un jeu de plateforme à la Mario serait difficile à réaliser.

keywords: 2D, vue latérale, tiles de 32x32, déplacement d'un "sprite" à coup de flèches haut bas gauche droite, scrolling.

Je me suis fait un "monde" d'environ 20'000 x 10'000 px, en dessinant à chaque fois toutes les tiles (optimisations niveau 0)... et bien ça scroll super fluide.

J'avais désactivé les appels update/repaint (que je gérais donc) et je n'avais qu'un seul thread, celui qu'on arrive dedans avec le main() :lol: .
Principe:

Code:

---

1 2 3 4 5 6 7 8 9

init() while(not quit) { mesureTempsEcouléDepuisDernièreBoucle traiteTouches() bougeObjets/événementsDuMonde // (en fonction du temps écoulé) dessineMonde() dessineObjets() attendre10ms() // pour éviter un CPU à 100%, pas très élégant :mrgreen: }

---

Voilà...
Ma question: pourquoi, systématiquement, vouloir faire des thread dans tous les coins? Je prétends qu'on peut faire un jeu sans faire de new Thread()...

Pour améliorer la gestion des événements utilisateurs, les touches mettent un flag à true/false selon qu'elles sont pressées ou pas. Ensuite, ces flags sont lus dans la boucle principale.

Bref...

ben lorsque tu as des ennemis qui ont des mouvements indépendants du personnage pricncipal, t'es obligé d'avoir un thread pour chacun puis un thread principal pour gérer ces sous-threads qui dessinent chacun un élément indépendant dans le backbuffer. Le coup du KeyPressed, ça marche seulement si ton personnage est seul au monde...

De plus, ta façon de prendre le thread du main et de le faire tourner à l'infini : :arrow: C'est franchement deg :furieux: :lol:

bon bon, 2-3 explications:

Citation:

---

De plus, ta façon de prendre le thread du main et de le faire tourner à l'infini : C'est franchement deg

---

faux, pour le thread principal il faut le faire tourner a l'infini avec une condition d'arret, un boolean pause par exemple

Citation:

---

En vrac, mon expérience dans le Java2D... ce fut une tentative de voir si un jeu de plateforme à la Mario serait difficile à réaliser.

---

intéressant, j'aimerais savoir comment tu as codé la physique du moteur, par exemple la maniere dont il saute et retombe, les collisions :D

Code:

---

1 2 3 4 5 6 7 8 9

init() while(not quit) { mesureTempsEcouléDepuisDernièreBoucle traiteTouches() bougeObjets/événementsDuMonde // (en fonction du temps écoulé) dessineMonde() dessineObjets() attendre10ms() // pour éviter un CPU à 100%, pas très élégant :mrgreen: }

---

loin de moi l'idée de vouloir critiquer, mais ce thread, je suppose que sa vitesse de rafraichissement (10ms ici) c'est pour les mouvements du héros, ok, mais les ennemis, et autres éléments du monde, ils sont calqués sur le meme système de mouvements ??? honnetement je doute

Citation:

---

J'avais désactivé les appels update/repaint (que je gérais donc)

---

bien :P

Citation:

---

attendre10ms() // pour éviter un CPU à 100%, pas très élégant :mrgreen:

---

ah bah, et mon thread avec yield et setPriority(Thread.MIN_PRIORITY); c'est fait pour quoi a ton avis ? :wink:

Citation:

---

Pour améliorer la gestion des événements utilisateurs, les touches mettent un flag à true/false selon qu'elles sont pressées ou pas. Ensuite, ces flags sont lus dans la boucle principale.

---

oui !!!!!!!!! ca il faut le faire c'est trop trop utile lol :D

Citation:

---

Ma question: pourquoi, systématiquement, vouloir faire des thread dans tous les coins? Je prétends qu'on peut faire un jeu sans faire de new Thread()...

---

le minimum pour un jeu a mon avis c'est 1 thread, celui du rafraichissement graphique (FPS), les autres qui dirigent le monde peuvent etre seulement des compteurs de temps ou l'utilisation de GageTimer (dll très très utilisées car précise et efficace)

Citation:

---

Je me suis fait un "monde" d'environ 20'000 x 10'000 px, en dessinant à chaque fois toutes les tiles (optimisations niveau 0)... et bien ça scroll super fluide.

---

sur un p'tit pc, il doit souffrir, faut utiliser un systeme de viewport afin d'économiser un maximum la mémoire utilisée

ben moi je prétend que c'est faux de vouloir faire tourner le thread du main à l'infini. Le thread du main doit lancer un thread de dessin principal qui lui boucle à l'infini avec une condition d'arrêt. Cela permet au thread du main de garder le contrôle suprême sur l'exécution du programme. En tout cas à mon avis cette méthode est bien plus propre...

Très intéressant tout ça... Je vais essayer de placer le dessin dans un thread. A la fin du dessin, je dois faire wait(20) ? J'avais essayé mais ça ne marchait pas : je crois que c parce qu'il n'y avait pas de thread...

Essayes ça :

Code:

---

1 2 3 4 5

try { Thread.sleep(20); } catch (InterruptedException e) { e.printStackTrace(); }

---

Glop : on peut le télécharger ton Mario ? (ou par mail...) Je serais curieux de voir ça ! :)

Merci miel_pops, je vais essayer.

Cool, il n'y a plus d'erreur maintent ! Mais ça ne fait pas ce que je veux... c'est normal, code à revoir, c pas fini !

Vivent les threads ! :P Là j'ai un beau scrolling fluide, bien plus agréable qu'avant, avec possibilté de faire varier la vitesse facilement (marche ou course).

Je soumets ma technique à validation d'experts :wink: :

J'ai créé 2 threads :
- un qui dessine
- un qui augmente la coordonnée y (pour l'instant on ne peut que monter !)

Je les lance comme ça :

Code:

---

1 2 3 4 5 6 7 8

Affichage affichage = new Affichage(); affichage.setPriority(Thread.MAX_PRIORITY); affichage.start();   Marche marche = new Marche(); marche.setPriority(Thread.MAX_PRIORITY); marche.start();

---

C'est conseillé la priorité MAX ? pour les deux ??

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

public class Affichage extends Thread {   public void run() { while(!quitter) { afficheEcranJeu(); try { Thread.sleep(1000/24); } catch (InterruptedException e) { e.printStackTrace(); } } } }     public class Marche extends Thread {   public void run() { while(!quitter) { if(marche) pix_y++; try { Thread.sleep(1000/48); // changer la fréquence pour varier la vitesse } catch (InterruptedException e) { e.printStackTrace(); } } } }

---

on keyPressed : marche = true
on keyReleased : marche = false

tu vois le multithread c'est top 8)
le mieux c'est un thread avec priorité minimale pour le rafraichissement graphique, étant donné que tu n'es pas a quelques FPS prets et ca permet de garder la priorité pour que les animations des sprites soient toujours nickel :wink:
a part ca t'as l'air d'avoir tout compris pour l'indépendance des physiques des objets dans un jeu, à toi de continuer :P

Citation:

---

Envoyé par narkotik

Code:

---

1 2 3 4 5 6 7 8 9

init() while(not quit) { mesureTempsEcouléDepuisDernièreBoucle traiteTouches() bougeObjets/événementsDuMonde // (en fonction du temps écoulé) dessineMonde() dessineObjets() attendre10ms() // pour éviter un CPU à 100%, pas très élégant :mrgreen: }

---

loin de moi l'idée de vouloir critiquer, mais ce thread, je suppose que sa vitesse de rafraichissement (10ms ici) c'est pour les mouvements du héros, ok, mais les ennemis, et autres éléments du monde, ils sont calqués sur le meme système de mouvements ??? honnetement je doute

---

Non, c'est pas pour les mouvements du héros. C'est pour
1) recalculer les positions/états des objets du monde (perso + montres + etc)
2) afficher une vue, un état du monde à un moment précis. On affiche tout ce qui est visible en fonction de l'endroit de la caméra.

Citation:

---

Citation:

---

attendre10ms() // pour éviter un CPU à 100%, pas très élégant :mrgreen:

---

ah bah, et mon thread avec yield et setPriority(Thread.MIN_PRIORITY); c'est fait pour quoi a ton avis ? :wink:

---

yield et setPriority servent à gérer les priorités / exécutions des threads dans la JVM. En principe, pas d'incidence sur le CPU alloué à la JVM.

Citation:

---

Citation:

---

Ma question: pourquoi, systématiquement, vouloir faire des thread dans tous les coins? Je prétends qu'on peut faire un jeu sans faire de new Thread()...

---

le minimum pour un jeu a mon avis c'est 1 thread, celui du rafraichissement graphique (FPS), les autres qui dirigent le monde peuvent etre seulement des compteurs de temps ou l'utilisation de GageTimer (dll très très utilisées car précise et efficace)

---

Les DLL c'est chouette, mais c'est pas portable... Répète après moi: "Les DLL n'existent pas" :lol:
Je fais tout dans le même thread. Séquentiellement:
1) je dirige le monde (©BillGates)
2) j'affiche le monde
Y'a pas de raison que ça marche pas, au contraire, et en plus y'a pas de problèmes de synchro (1 seul thread), pas de risque de "tuer" un objet pendant qu'on le lit pour affichage... Et le CPU que tu utilises pour ordonnancer les thread, chez moi il est utilisé pour le jeu :wink:

Citation:

---

Citation:

---

Je me suis fait un "monde" d'environ 20'000 x 10'000 px, en dessinant à chaque fois toutes les tiles (optimisations niveau 0)... et bien ça scroll super fluide.

---

sur un p'tit pc, il doit souffrir, faut utiliser un systeme de viewport afin d'économiser un maximum la mémoire utilisée

---

Pas de soucis sur un p333 avec 96MB de RAM... j'ai rien de plus faible sous la main...

Bon, sinon, à chacun son truc, je pense pas qu'on puisse objectivement dire que l'une des deux philosophies (avec ou sans thread) est meilleure que l'autre...

Bien entendu, avec un seul Thread, y'a certains problèmes qu'il faut gérer différemment. Par exemple, change pas la position de ton perso à x=x+5 quand tant que la touche "droite" est enfoncée. Par contre, tu mets sa vitesse vX à 5 quand tu presses la touche, et tu la remets à zéro quand tu la lâche.
Quand on passe dans la partie "mise à jour du monde", on sait combien de temps s'est écoulé depuis la dernière MAJ, disons T, et du coup on peut calculer la nouvelle position du perso: x = x + t*vX.

Même chose pour les monstres, la partie AI décide où ils vont et change leur vitesse.

La partie affichage ajuste la caméra sur le perso et affiche les objets. Voilà...

Citation:

---

Envoyé par Pascmar

ben moi je prétend que c'est faux de vouloir faire tourner le thread du main à l'infini. Le thread du main doit lancer un thread de dessin principal qui lui boucle à l'infini avec une condition d'arrêt. Cela permet au thread du main de garder le contrôle suprême sur l'exécution du programme. En tout cas à mon avis cette méthode est bien plus propre...

---

Je fais un while tout à fait normal, et dedans je teste un boolean qui indique pour savoir si, par exemple, l'utilisateur a pressé ESC... rien ne tourne à l'infini, en tous cas pas plus que dans les autres while que j'ai déjà rencontrés :wink: Et le thread "main" garde le contrôle suprême, puisque y'a que lui qui tourne :lol:

je viens de tester ta méthode, c'est vrai que ça marche bien, seulement, je me demande comment tu fait pour gérer les collisions parce que l'intérêt que je vois à la méthode des "multi-threads" est que comme chaque élément graphique est un objet indépendant, on lui donne un int pour sa position et il est facile de comparer les positions des threads entre-eux et de là, supprimer s'il le faut un des threads impliqués dans la collision. De plus il est assez pratique de gérer un vecteur ou une liste de threads, beaucoup plus qu'un seul qui fait tout. Mais autrement, c'est vrai que côté CPU, c'est pas vraiment la joie :lol:

Code:

---

1 2 3 4 5 6 7 8 9

init() while(not quit) { mesureTempsEcouléDepuisDernièreBoucle traiteTouches() bougeObjets/événementsDuMonde // (en fonction du temps écoulé) dessineMonde() dessineObjets() attendre10ms() // pour éviter un CPU à 100%, pas très élégant :mrgreen: }

---

ce système est pas mal mais il comporte malheureusement un point faible, le mouvement n'est pas parfaitement fluide pour des déplacements a grande vitesse, j'm'explique:
le rafraichissement graphique est toute les 10ms:
si ton héros se déplace de 2pixels a chaque rafraichissement, c'est fluide ok
si ton héros se déplace de 100 pixels a chaque rafraichissement, c'est pu fluide du tout, ca va saccader
j'ai pris le cas du héros mais ca peut etre n'importe quoi, un astéroide, un monstre, un missile, une balle, qu'importe...

Citation:

---

Les DLL c'est chouette, mais c'est pas portable... Répète après moi: "Les DLL n'existent pas"

---

La DLL GageTimer est super super connue lol, et il est aussi connue qu'elle existe pour la plateforme Unix :D
elle a été crée pour faire des jeux et palier le probleme de Java qui ne peut accéder aux nanosecondes (celui ci n'apparait qu'avec Java 1.5), il gere aussi les collisions, le Parallax Scrolling ( scrolling de différents plan à l'écran, style Mario Bros et autres), le Non-blocking sound effects mixer, il permet aussi de gérer la vitesse de keyboard pour récupérer les touches.

Citation:

---

Y'a pas de raison que ça marche pas, au contraire, et en plus y'a pas de problèmes de synchro (1 seul thread), pas de risque de "tuer" un objet pendant qu'on le lit pour affichage...

---

c'est pour ca qu'il existe le mot clé synchronized, pour éviter d'utiliser une ressource en cours d'utilisation :wink: