Well... I could. It could run into to speed issues, but I'd have to try it out to be sure. In any case, its more efficient just to look forward and predict when I need to bounce. The only other practical solution I see is to have the game logic be decoupled completely from- and run at a faster "frequency" or have shorter "ticks" - than the rendering process.

It wouldn't be any slower than using a separate thread to move it forward 1 pixel at a time, and in fact would probably be faster. Running your physics at a faster rate would also not decrease the amount of collision checks either, and would probably be even harder to synchronize. All in all, the simplest solution is often the best. Moving an object and checking for collision takes very little time to do compared to even drawing the image to the screen, and I think it could save you a lot of time writing code to do things like extremely complicated multi threaded engines just to do something like parabolic motion.

But doesn't moving an object and checking for collision entail a repaint every time I move? Or am I not understanding Greenfoot? When exactly is a repaint called? I realize that the separate thread to move it forward 1 pixel at a time was probably a stupid idea speed-wise. It would look a lot better though. To be honest, I think the simplest solution is to just keep a list of the locations of all platforms currently in existence and just check that. It would probably be the fastest solution.

A full re-paint is not performed every time an object moves. If the simulation speed is reasonably fast, many movements are possible between repaints. I can't recall exactly without looking at the source but I think repaints are limited to about 70Hz.

Oh... I see. That's a useful fact to know. Alright, I should probably get around to finishing my project (due monday!) instead of discussing finishing it here. The wonders of procrastination! :P

The below is derived assuming a high-res worlds. They seem to remain constant regardless of the boundedness of the world. Any errors, misconceptions, or wrong conclusions are mine alone and I apologize in advance. I spent more time than I should have using MS-Paint-fu, and yes, a magnifying glass, to figure this out. Conclusion: Greenfoot cells are addressed in array-like style. (I'm pretty sure that's common knowledge). Conclusion: The grab mouse cursor always disappears once you *drop* an image. You cannot move an actor by to the edge of the world by clicking it and dragging outside of the border. super(1,1,1) creates a single-pixel world. Greenfoot attempts to put a border onto the world, but it can only just fill the 1-pixel world with black. However, a grab mouse cursor still appears when you mouseover the pixel if you have an actor there. super(2,2,1) creates a 2*2 world. Greenfoot draws a border onto the world, creating a 2*2 black dot. All actors are invisible, just like the 1*1 world. A grab mouse cursor appears if you mouseover the top left pixel, if you have an actor there. super(2,1,1) creates a 2*1 world. Greenfoot's border drawing algorithim fills the entire world with black. Grab mouse cursor still appears when you mouseover the leftmost pixel. You can still move the actor around. Conclusions: The border drawing algorithim draws onto the world you specify, aka, a blank world calling super(700,700,1) creates a 700 by 700 world, with a white rectangle 698 by 698 and a 1 pixel black border. In short, the border is drawn to the world, and not around. Mouse actions do delegate through to anything beneath the border. This was also checked using Greenfoot.mousePressed(); Also, mousePressed() does take into account the graphical extent of the actor. I assume related methods behave the same. Conclusion: getHeight() and getWidth() of world returns the world's screen extent, even for unbounded worlds. addObject(new FourByFourTest(), 1, 1) places the pixel at 2,2 in the image at pixel 1,1 in the world. In other words, the third pixel down and right in my TwoByTwoTest's image is mapped to the second pixel down and right in my world. Remember, the border counts. addObject(new SixBySixTest(), 1, 1) places the pixel at 3,3 in the image at pixel 1,1 in the world. In other words, the fourth pixel down and right in my SixBySixTest's image is mapped to the second pixel down and right in my world. Conclusion: The center of an image is defined as the pixel at (using array-like addressing, with the top left corner of the image as the origin) (int) (imageWidth/2), (int) (imageHeight/2). So for a four by four image, the imageWidth/2 is 2.0. Casted to an integer, it is 2. Repeat for the y coordinates, and you get 2,2. Using array-like addressing, this is the third pixel down and right. For a three by three image, the imageWidth/2 is 1.5. Casted to an integer, it is 1. Repeat for the y coordinates, and you get 1,1. Using array-like addressing, this is the second pixel down and right, or the logical center of a world. Conclusion: Greenfoot does not allow the center, as above defined, to leave the world, not counting borders. This applies even if part of the image on every side will be cut off.

I'm not actually sure what you mean by that. (If it's just that two indices can be used to select a cell, then yes, that's true). That sounds like a bug, actually. The border should be around the outside of the world. I'll have to look into that. The center of an image is not defined that precisely. There's a difference between implementation, which by its nature has some specific behaviour, and the interface which is implemented, which might leave that behaviour unspecified. Technically different implementations might differ on the behaviour in this case (even different versions of Greenfoot, though it's unlikely). The implementation makes a best effort to calculate the exact centre of the image where appropriate. For instance, if the world's cell size is 2x2, an object whose image is an even width and height will be centred exactly over its cell location. That is true, if the world is unbounded, but I find it simpler to equate your "center" with the object location and then we can just say that "the object cannot leave the world".

When I say array-like, I mean that it starts with 0. I'll admit I used "defined" loosely. I should say "implemented", as you said. As I said above, this is for high-res worlds only. Both work, although one needs to remember that bits of the object image can leave. Um, you mean bounded, right?

Ok - the proper name for that is "0-based indexing" (as Java arrays use), though in this case the x/y values aren't really meant to be so much indexes as they are distances from the top left cell. Regardless we could say that the co-ordinates are "0-based". Yes, I meant bounded, sorry.