Hey, that code worked perfectly! Thanks!

That is, black background and white pixels moving towards and "past" the screen. I suspect this is a common question, but I coundn't find a thread about it using the search function so here it goes.

What I want to do is have this feature as background in a Tetris clone I'm writing so that the area around the playing field will be moving space.

This sounds a lot like something which could (should) be implemented using a particle system. Has anyone got any advice, code examples or useful links to tutorials etc?

It worked. Thanks!

Like this:

img = Toolkit.getDefaultToolkit().getImage("image.gif");

and:

codeBase = new URL("file:" + System.getProperty("user.dir") + "/");
soundURL = new URL(codeBase,"sound.wav");
theSound = Applet.newAudioClip(soundURL);

When I make a jar archive from my .class-files and the image and sound file I use in the program (all files in program root directory) and execute it, the image and sound are not loaded unless they are in the directory in which the jar-file is. That is, although they are inside the jar-file, they have to be in the same directory as the jar-file too.

I create the jar-file using (I've also tried *.* for the files to be included):

jar -cmf manifest.mf game.jar *.class image.gif sound.wav

And run it using (the program starts, only it doesn't play the sound and doesn't display the image):

java -jar game.jar

Anyone know what I'm doing wrong?

Sometimes threads are the optimal solution, sometimes they are not, no point in flaming each other arguing that one is always better than the other. Personally, I find that threads are an incredibly convenient way of solving a lot of programming issues as well as making code and design more easy to understand. However, it is not always suitable to use threads. Since I haven't written an application like this one before (well, not finished one anyway) I'll try a few different techniques and see what works best in practice, which is what matters.

I've used the Thread class in lots of applications, in fact I used it in a similar game to this one a year or so ago. I found however, that the movement of the ball was still somewhat jerky. That time I didn't finish the game so I didn't really bother investigating the problem any further. It seemed it was the JVM or something that was a bit jerky sometimes with half-a-second flickers from time to time.

For my current game I'm currently using frame-based movement (i.e. I move the ball a certain amount each frame) and it works really well so far though I am a bit reluctant to this kind of programming. I might try using a thread and compare the results, after all I've taken a number of courses in realtime programming and the beauty of using threads cannot be overstated.  

Actually, I'm just realizing that. Since the "normal" per-frame movement of the ball is a just few pixels, it will be _really_ difficult to do any kind of adjusting to account for a varying framerate. If just a little more time than that which would represent one "unit step" of the ball has passed, it would instead move twice as fast at 2*"unit step". Unfortunately(?), the resolution of the movement is too crude to be used for adjusting the speed. If the "normal" step size would be 50 pixels, the situation would be another, one could then tune the speed much better. If you know what I mean.  

Yup, thought about doing it like that. I hope the accuracy/resolution of System.currentTimeMillis() is good enough for this. If not, I suppose movement may become less smooth than desired. Well I'll just have to try it and find out.

I'm writing an Arkanoid/Breakout clone in Java (fullscreen exclusive mode). What's the best way to make the movement/speed of the ball independent of framerate? Currently I do step() (which moves the ball a certain number of pixels in x and y) once every frame. Obviously, this isn't what one would like, I just did this for testing purposes. So, is there an optimal way of handling the movement? Suggestions?