Debugging waves with onPaint()

Jump to navigation Jump to search

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Robocode/Graphical Debugging/Debugging waves with onPaint()/reply (5).

I assume you're referring to if you use the "getGraphics()" call instead of implementing "onPaint()" right?

At least personally I don't care for that approach because then either your bot will spend CPU time on the painting when painting is disabled, or you have to check if onPaint is called anyway.

Rednaxela18:34, 17 May 2012

Using getGraphics() also works. But I am implementing onPaint and storing an object in a member variable (that object contains the Graphics object), which is then consumed in the run() method. That variable is cleared before calling execute() (in case debug is disabled in the middle of a battle). It is bulky, but it is fast.

If painting is disabled, onPaint is not called and nothing is setted in that variable. Yep, there is one check to see if the variable was set. The onPaint event is treated a bit differently (separated queue) from other events to make it easier to process it at the end.

MN20:03, 17 May 2012
 

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.

Chase-san00:55, 18 May 2012

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).

MN15:29, 18 May 2012

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

MN15:35, 18 May 2012
 

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

Chase-san04:23, 19 May 2012