Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


[java] applet game loop


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Daniel Miller   Members   -  Reputation: 218

Like
0Likes
Like

Posted 24 July 2006 - 03:43 PM

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?

Sponsor:

#2 avidlinuxuser   Members   -  Reputation: 100

Like
0Likes
Like

Posted 24 July 2006 - 04:07 PM

It's a little old. I wrote this about 2 years ago. However, it still works. Here it is.

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.

#3 Daniel Miller   Members   -  Reputation: 218

Like
0Likes
Like

Posted 24 July 2006 - 07:43 PM

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]

#4 Alrecenk   Members   -  Reputation: 400

Like
0Likes
Like

Posted 25 July 2006 - 12: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.

#5 Daniel Miller   Members   -  Reputation: 218

Like
0Likes
Like

Posted 25 July 2006 - 06:04 AM

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.

#6 Alrecenk   Members   -  Reputation: 400

Like
0Likes
Like

Posted 25 July 2006 - 07:09 AM

You can allow your run method to finish and that will stop the thread.

#7 avidlinuxuser   Members   -  Reputation: 100

Like
0Likes
Like

Posted 25 July 2006 - 07:22 AM

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.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS