[java] applet game loop
Author
I've been perusing the internets in search of a standard game loop for a java applet, but all of the examples I have found are multithreaded. I would think that's overkill (at least in C#/C++ it usually is), but is that what's required of an applet that needs to update regularly regardless of input?
It's a little old. I wrote this about 2 years ago. However, it still works. Here it is.
To add input, have an boolean array with a decent size (512 should be enough). In the keylistner, have something like keys[keycode]=true. In your object update method ie update(long time), check to see if a particular key is pressed and, update as necessary.
Edit: The only reason it needs an extra thread is because you want to do active rendering. Otherwise, you will have to wait until the AWT Thread flushes the events before another repaint is triggered. Also, any input detection on your part delays the AWT Thread even more.
import java.awt.Canvas;import java.awt.Graphics2D;import java.awt.Dimension;import java.awt.image.BufferStrategy;import java.applet.Applet;/***AppletGameCore.java*@author David Graham*/public abstract class AppletGameCore extends Applet implements Runnable{ private BufferStrategy bufferStrategy; private Canvas drawArea;/*Drawing Canvas*/ private boolean stopped = false;/*True if the applet has been destroyed*/ private int x = 0; public void init() { Thread t = new Thread(this); drawArea = new Canvas(); setIgnoreRepaint(true); t.start(); } public void destroy() { stopped = true; /*Allow Applet to destroy any resources used by this applet*/ super.destroy(); } public void update() { if(!bufferStrategy.contentsLost()) { //Show bufferStrategy bufferStrategy.show(); } } //Return drawArea's BufferStrategy public BufferStrategy getBufferStrategy() { return bufferStrategy; } //Create drawArea's BufferStrategies public void createBufferStrategy(int numBuffers) { drawArea.createBufferStrategy(numBuffers); } //Subclasses should override this method to do any drawing public abstract void draw(Graphics2D g); public void update(Graphics2D g) { g.setColor(g.getBackground()); g.fillRect(0,0,getWidth(),getHeight()); } //Update any sprites, images, or primitives public abstract void update(long time); public Graphics2D getGraphics() { return (Graphics2D)bufferStrategy.getDrawGraphics(); } //Do not override this method public void run() { drawArea.setSize(new Dimension(getWidth(),getHeight())); add(drawArea); createBufferStrategy(2); bufferStrategy = drawArea.getBufferStrategy(); long startTime = System.currentTimeMillis(); long currTime = startTime; //animation loop while(!stopped) { //Get time past long elapsedTime = System.currentTimeMillis()-currTime; currTime += elapsedTime; //Flip or show the back buffer update(); //Update any sprites or other graphical objects update(elapsedTime); //Handle Drawing Graphics2D g = getGraphics(); update(g); draw(g); //Dispose of graphics context g.dispose(); } }}To add input, have an boolean array with a decent size (512 should be enough). In the keylistner, have something like keys[keycode]=true. In your object update method ie update(long time), check to see if a particular key is pressed and, update as necessary.
Edit: The only reason it needs an extra thread is because you want to do active rendering. Otherwise, you will have to wait until the AWT Thread flushes the events before another repaint is triggered. Also, any input detection on your part delays the AWT Thread even more.
Author
Ok sweet, I wasnt sure whether I should be calling update like that, but I guess I can.
thanks!
edit: Should you be calling run() yourself?
[Edited by - Daniel Miller on July 25, 2006 2:43:27 AM]
thanks!
edit: Should you be calling run() yourself?
[Edited by - Daniel Miller on July 25, 2006 2:43:27 AM]
It is my understanding that several standard parts of java are multithreaded(such as garbage collection and just about anything event driven). Is there any particular reason you want to avoid having mutliple threads? I usually put my main game loop inside a timer event. Which, aside from just being easy, also means that it will wait between between calls and not take all of the processing power.
Author
OK, I have decided to implement Runnable, but I have one question. How do I know that the thread is killed? stop() is depreciated, so I'm not sure which method to override.
edit: apparently you do override stop(). weird.
edit: apparently you do override stop(). weird.
Quote:Original post by Daniel Miller
OK, I have decided to implement Runnable, but I have one question. How do I know that the thread is killed? stop() is depreciated, so I'm not sure which method to override.
edit: apparently you do override stop(). weird.
When an applet is destroyed, all the threads will be joined after destroy() is called. In this case, destroyed is called in one thread. Control is then handed to the game update thread. Stopped is now true so it falls out of run. You would probably want to send a wait command in destroyed and then notify the thread after run has completed. Like I said, it is old. I could probably design something much better now.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
