If you're going to do it - why not make it easy?

AnimatedApplet was created to make it easy for you to write Applets with smooth animation, mouse- and keyboard input.

If you are going to write an Applet with animation in it, subclass one of these three classes, and voila, you don't need to think about making the animation smooth or getting the input from mouse or keyboard - it's already there for you to use.

A subclass of AnimatedApplet written with only 553 characters.

AnimatedApplet
Let's begin by explaining the base class: AnimatedApplet.
AnimatedApplet uses multibuffering, a technique used to minimize screen flicker and maximize the time left over for computing tasks in your Applet.

There is a basic construction you must understand to use this applet fully:
There are two Image classes. One is intended to contain the clean background, and the other is intended to be the mixer while creating the next visible "slide".
The clean background is created and painted during the initialization phase (when the Applet is first created), and then only seldomly changed (only if the background for your applet is supposed to change).
Every time paint() is called, the clean background is copied to the mixerImage, and all necessary items are painted on the mixer Image. Finally the mixer image is painted to the screen. This minimizes flicker, because we paint to mixerImage, and copy to the screen afterwards, instead of painting to the screen while the mixerImage is being repainted. It also minimizes the processor work due to the fact that the background is created once, when the Applet is created, instead of once for each screen update.

To make animation as even as possible, the thread that calls repaint() doesn't sleep a fixed number of milliseconds, but only the needed amount to make the screen updates as regularly spaced in time as possible.
This minimizes the risk for lag in screen updates during hefty calculations in your Applet.

AnimatedApplet and subclasses hereof makes it easier for you not to screw up when accessing the methods already created. If I wrote a run() method, an init() method, etc. and you wanted something done at those times as well in a subclass, then you'd have to overwrite my method, and call the superclasses version from within you method. But what if you forgot the super.init(); call? No functionality and finding the bug could be pretty hard. So for every method you might want to write some code in, there is a custom version for you, which is called from AnimatedApplet.
This means that there is a customRun(), customInit(), customStop(), customStart(), customPaint(Graphics g) method, and they are all called from the base methods.

For example:

Let's say you want a little thingy to bounce around an applet. This would require writing a custom paint() method, which painted the little thingy, and writing a custom run() method which updated the position of the thingy.
So you overwrite the customPaint(Graphics g) method and paint the thingy through the Graphics parameter. This will double buffer the drawing for you, without needing any work on your part.
Then you overwrite the customRun() method making sure to check whether the thingy is hitting a border.

That's all there is to it!

Take a look at the samples below or the link under the applet above, to see what I mean.

AnimatedMouseApplet
AnimatedMouseApplet is a subclass of AnimatedApplet, and therefore has all the functionality of AnimatedApplet.
On top of that, AnimatedMouseApplet is a MouseListener and a MouseMotionListener and keeps the mouse's x, and y-coordinates readily available via the getMouseX() and getMouseY() methods. You can always poll the state of the right and left mousebutton via the public fields LEFT_MOUSEBUTTON and RIGHT_MOUSEBUTTON.
And if you want to write your custom handling of any of the mouseevents, you can overwrite the custom versions (see the codesamples via the link below).
But remember to include the MouseEvent in the parameters list, or you won't be overwriting, but overloading. : )

AnimatedInputApplet
AnimatedInputApplet is the class to inherit from if you want access to both mouse- and keyboard input.
It is a subclass of AnimatedMouseApplet and is a KeyListener on top of all the other stuff.
This means that you can get all keypresses, keyreleases and keytypes, and some of the dirty work has already been done, so the state of the control, alt and shift keys can be read from the boolean fields CONTROL_KEY, ALT_KEY and SHIFT_KEY.
If you want custom behaviour from any of the keyevents, just overwrite customKeyPressed(KeyEvent e), customKeyReleased(KeyEvent e) or customKeyTyped(KeyEvent e).

Samples to show how little code is needed to make nifty stuff.

Download