0

So far I have gotten this applet to a working stage; The only problem is that it only works if the mouse is moving; If the mouse is not moved, then the entire thing grinds to a halt. It starts working again if the mouse is moved.

The way that it works is the paint method is called by mouseMoved method. Each time the the mouse is moved, it goes threw the paint method, and the game continues. The problem arises from when the mouseMoved method isn't called, so the paint method does not get called, and the entire thing just pauses until the mouse is moved.

I have tried the following:

Having the paint method be recursive so it will call itself. The problem with this is that then the mouselistener does not work, because the program is to busy painting a bunch of stuff moving around.

I also tried using threads so that the mouselistener would interrupt the paint method. This did not work, although this could have been because I do not understand how threads worked. If anyone knows how to implement this, it seems like it would work.

Here is the snip-it of code of the problematic areas;

  public void paint( Graphics gr) {
     if( Earth != null){

        displayWorld(Earth);
        for(int a =0; a < 100; a++){      
           Earth.run();
           Earth.Worlds.get(2).forceMove(x,y);
          }
        try
        {
           Thread.sleep(100);  
        }
           catch (InterruptedException ie)
           {}   
     }

  }

public void mouseMoved( MouseEvent e ) {
     x = e.getX();
     y = e.getY();
     Graphics gr = getGraphics();      
    paint(gr);
  }  

2 Answers2

2

I'd suggest taking another look at threads. This is a pretty standard problem in game programming (and in other areas of programming too) - you have one thread, looping forever, containing your game logic. It updates your player's position, calculates, health, whatever, or it sleeps if there's no work to do. If work is done which requires the applet's graphics to be redrawn then your thread calls repaint() which sends a repaint request to the event dispatching thread (a special thread that gets created automatically in every Java program).

When the player moves their mouse or provides keyboard input, your event listeners update your program's data structures (and pokes the main thread in case it's sleeping).

These links to previous StackOverflow questions involving Java games might be a good jumping-off point:

Best way to implement game loop without freezing UI thread

game loop - threads

good luck!

Community
  • 1
  • 1
Dan O
  • 6,022
  • 2
  • 32
  • 50
  • Good idea; I'm sure that doing this properly with threads will be beneficial in the long run, especially once I move onto some other projects. I will definitely use threads for the next versions/levels if I make more. – rockclimber Aug 23 '12 at 03:34
1

So, your paint process is reliant on the mouse moving?? So you need some kind of way to tell the applet to update itself??

private javax.swing.Timer paintTimer;

public void start() {
    // Your normal setup...

    paintTimer = new javax.swing.Timer(250, new ActionListener() {
        public void actionPerformed(ActionEvent evt) {
            Graphics gr = getGraphics();      
            paint(gr);
        }
    });
    paintTimer.setRepeats(true);
    paintTimer.setCoalesce(true);
    paintTimer.start();
}

public void mouseMoved( MouseEvent e ) {
    x = e.getX();
    y = e.getY();

    // You could wait for the timer to trigger the repaint for you...
    repaintTimer.restart();

    Graphics gr = getGraphics();      
    paint(gr);
}  

You're going to need to play around with the timing though

MadProgrammer
  • 343,457
  • 22
  • 230
  • 366
  • Do *not* use `javax.swing.Timer` here. There's no reason. Have you looked at `java.util.Timer`? – obataku Aug 23 '12 at 03:22
  • @veer why not? What am I missing? – MadProgrammer Aug 23 '12 at 03:23
  • Why `Graphics gr = getGraphics(); paint(gr);` instead of just `repaint();`? – Andrew Thompson Aug 23 '12 at 03:38
  • @AndrewThompson cause that's what was given to me. I didn't want to assume how the graphics where been updated. If the OP is using the normal repaint process, then yes, you are right (as usual ;)), but I had no evidence to suggest it one way or the other :P – MadProgrammer Aug 23 '12 at 03:48
  • *"I didn't want to assume"* I dislike it as well, which probably explains why I'm such a big fan of the SSCCE. ;) +1 – Andrew Thompson Aug 23 '12 at 03:52
  • @AndrewThompson had it been a "normal" applet question, I would have suggested it, but given it's a game related question, I didn't know if they were painting to a buffer first or not and rendering later...:P – MadProgrammer Aug 23 '12 at 03:54
  • Thanks so much guys! It works perfectly, thanks to the timer. I used javax.swing.Timer. – rockclimber Aug 23 '12 at 14:55