Floatation

1. Failure to take proper advantage of the G4's floating point instructions;
2. Performance loss due to the introduction of casts;

According to my benchmarks, the first point is a myth - Java integer performance generally exceeds Java floating point performance on the G4.

Next, I converted Lowlife3D to use floating point coordinates, for the positions and velocities of all the nodes in the system.

I changed the type of the "x", "y", "z", variables, and that of the "dx" and "dy" variables, and then followed the list of compiler errors sorting everything out. My liberal use of shift left to perform division by two was replaced by an ordinary division by a similar quantity. If things got too hairy, I cast things to integers and left things as they were.

I timed this process. It lasted one-and-a-quarter hours from deciding to do it, to getting a compiling floating point version. If I ever have to do it again, it will be quicker.

Then I compared perfomance. In summary, after turning off all the display options (in an attempt to remove noise from my benchmarks), the result was that the FP code ran at about 60% of the original integer code on my machine - before I made any attempt at getting rid of all the unnecessary divisions.

You can see the results of this yourself if you like. The integer version is at: http://atoms.org.uk/lowlife3d/ and the floating point version is at: http://atoms.org.uk/lowlife3d/fp/.

I am going to discard the floating point version of the code (it's a really dumb way to do things).

However, it demonstrates a (very stupid) way in which the code can be used in a "float" environment, without excessive performance loss.

Any use of floating point coordinates for the creatures will result in a cast to integers for every node in every frame anyway - during the process of re-allocating them to bins.

I estimate that the performance loss by casting things in the right place will be far smaller than the performance gain of using integers for all the maths.

As far as I'm concerned, this is not a worthwhile issue. If you really want, I can now build a "float" version of the code. This would probably only run (slightly) more slowly on G4s - and would probably be harder for me to compensate for cumulative rounding errors in.

There's no reason to do this. I really think it would not be a good move.