It could be done. The egning would have to be changed a bit, but it wouldn't be that hard. :) Unfortunately, GreenfootImage is a bit slow, and i need to figure out how to write to the awt image directly XD

Speaking from experience, you might find this a bit harder than it first appears. I believe that your raytracing algorithm works perfectly for any solid defined by a mathematical function, but I think you could have problems when you define your solid through polygons instead of a function, as you are doing here. Your code is a bit tricky to read (consider intrinsic variable naming?), but I must say I am impressed, particularly with the spherical texture mapping! Do you intend to design lighting shaders as well for your engine?

"Unfortunately, GreenfootImage is a bit slow, and i need to figure out how to write to the awt image directly XD" GreenfootImage.getAwtImage() ..?

@Zerg: A polygon could just be an equation for a plane with some bounds on it. For example, if you wanted to map a triangle, you would first find the plan that it lies on, and find the point at which the ray collides with the plane. If the point is inside the triangle, go to linear interpolation for the mapping. And yeah, my code is a bit messy and hard to read right now, i hope to clean that up in the future. And normal shading might not be out of the question, after all it only takes a bit of multiplication. @Mjrb I am aware of that, i am just experimenting with Graphics and Graphics2D to see how I can maximize speed.

Using triangles results in slow-down issues--not only do you have to find where it intersects, you then have to make sure that it is contained within the triangle. Then you have all the fun of iterating through all the triangles. The biggest issue I think is that Greenfoot/Java was not intended to be able to solve multiple simultaneous equations quickly while iterating. I believe I have read though on some OpenGL for Java... not sure where you would find it, but that would be the way to go for 3D anything.

The slowdowns you talk about are always pressent, even in this scenario. Finding whether or not a point is inside a polygon is trivial using normals and dot products. The multiplication is Trivial compared to the trig needed for rotation, and the slowdowns that come from reading and writing from greenfootimages. I think I may have discovered a way to make at least the graphics faster though. Converting an image to 3 arrays of color bytes could speed up reading from images, and writing directly to the writable raster of an image drasticaly decreases writing times, and gives more control over color manipulation.

I would disagree. Finding whether or not a point resides within a triangle requires solving a simultaneous linear equation set in 3 variables--not trivial for a computer!

There is more than one way to find whether or not a point lies inside a triangle. The way you said works, as does computing the normals of the sides, then finding the dot product of the point against the normal. The dot product returns a positive number if the point is inside, and a negative if outside. Calculating the normal is trivial given the coordinates of the vertexes of the triangle, and the dot product is merely multiplication and addition. Do this for all 3 sides and your good :/ I do this in my rigid body physics simulator to detect collisions, and let me assure you, it is quite fast.

There is also the linear equation set for determining where the point intersects the plane. This would normally be no problem, but you have to do this for each polygon in the scene to determine which on is "on top" relative to the camera (unless you want to disregard all shading). Like I said, I am speaking from experience; my rasterizer posted previously used this method(minus Z-buffer), and was indeed quite slow. Just want to point out as well that your rigid body simulator is not running 40000(200px by 200px image)+ iterations per act cycle per object, and is also in 2D, not 3D. ... Of course, there really is no better method than yours. :P

mmm... I lied to you... There is a way to do intersection with polygons with only a single linear equation--still not trivial, but also faster. It requires a form of vector parametrization (which may not be trivial) along with the equation for the plane.

Yes I know. http://local.wasp.uwa.edu.au/~pbourke/geometry/planeline/ Simpler than you might think, and requires stunningly less math than a sphere, and even less to transform the image coordinates.

I suppose I could put a cap on the quality settings :P I hadn't even thought of lowering the quality that much! XD

you have bag when do zoom and bad quality! the game stopped!! in quality 9.00+.... and the best zoom(most big) its a bag