Thread history

Well keep in mind that the difference between onPaint and getGraphics are twofold.

First if I recall, the painting done by getGraphics is synced better with your current activity. Also you don't have to store any of your painting data for later to paint (which if I recall is part of the sync issue).

Which makes getGraphics much more useful for debugging then onPaint in my humble opinion. Where as onPaint is better for fancy graphics for everyone else after it is released.

The approach I told above is based in gathering all event data first, then process everything, only then do some output. Shift from an event driven architecture to a simpler request driven (input/process/output) architecture.

The main advantage is not being constrained with event ordering. Event ordering in Robocode doesn´t give any extra information. The main drawbacks are increased codesize (not an option for nanobots), and necessity of member variables (not an option for perceptual bots).

Of course, for private/temporary debugging, entangling draws and sysouts in the middle of other events is fine.

This is what I kind of what I figured the painting was for in the first place. :)