if(getX() == getWorld().getWidth()) setLocation(0, getY()); else if(getX() == 0) setLocation(getWorld().getWidth(), getY()); if(getY() == getWorld().getHeight()) setLocation(getX(), 0); else if(getY() == 0) setLocation(getX(), getWorld().getHeight()); This checks if you are at one of the Worlds edges. if its true, your Actor sets its Location to the other edge Hope that helpes =)

I found a problem in that method. It goes one way but not the other. I changed it a little. if(getX() == (getWorld().getWidth()-1)) { setLocation(0, getY()); } else if(getX() == 0) { setLocation(getWorld().getWidth(), getY()); } if(getY() == (getWorld().getHeight()-1)) { setLocation(getX(), 0); } else if(getY() == 0) { setLocation(getX(), getWorld().getHeight()); }

That would be the easiest and cleanest way to do it.

Even better would be to use '%' when making the object move. Let say you have a variable or two to show horizontal and vertical speeds (increments: positive for down or right, and negative for up and left) and the absolute value of which determines how far (speed) to move in that direction. Then the code could simply be: and the first two lines in the method can be eliminated by replacing dX and dY with those values in the final statement. Then, if this method is only called from only one place, it is not worth having a separate method for it; you can insert the setLocation statement in the code that calls it, instead of calling it. Another plus to this is that there are no 'if' statements; your program will run faster!

I think this is an untested assertion... it's true that a mispredicted branch can cause a stall on modern processors, but:

• division (and modulo) are also slow
• the compiler may be able to convert the "if" statement into non-branching code
• Java performs dynamic profiling and will arrange so that the branch is normally predicted correctly by the processor, meaning you only take the penalty on those relatively rare cases where an object does actually wrap across the world edge.

Finally, the drawing of an object's image takes so long compared to a simple "if" statement that you would not be likely to notice it. (I'm not saying that the code is a bad suggestion - but I disagree with the assertion that it will be faster).

Maybe I am too 'old-school'. It used to be that the 'if' statement was frowned upon because of the drain on execution time. The processors are so much faster now-a-days that the noticability of the effect is negligable. As far as 'dynamic profiling', I will have to check into that (something else that is new to me). I DO appreciate your input, as I am continuing to learn! Thanks again, Davin. :+) DAN

No worries Dan, there is a saying amongst wise programmers (wiser than me...) which varies in exact form but usually boils down to: "Optimization: don't do it. And if you do it, measure the impact to be sure it's really working." Processors and compilers (especially the Java runtime compiler) are so complex these days that it is rarely worth making micro-optimizations. I'm a little worried that I coined the term "dynamic profiling" myself. I simply mean that the code is instrumented at run time to discover which code is executed most frequently and which branches are likely to be taken (or not taken); when the Java bytecode is converted to native machine code as part of the JIT compilation process, the data from this instrumentation is taken into account. There is a small amount of information on this on the Wikipedia page for JIT compilation.