Talk:Robocode/Graphical Debugging

From RoboWiki
Jump to: navigation, search

Anybody else running into these two issues?

RobertWalker 04:01, 13 May 2009 (UTC)

No, but I'm running into a different one. I just haven't taken the time to troubleshoot it and file a report yet.

java.nio.BufferOverflowException
	at java.nio.Buffer.nextPutIndex(Buffer.java:501)
	at java.nio.HeapByteBuffer.putInt(HeapByteBuffer.java:347)
	at net.sf.robocode.robotpaint.Graphics2DSerialized.put(Graphics2DSerialized.java:1760)
	at net.sf.robocode.robotpaint.Graphics2DSerialized.setColor(Graphics2DSerialized.java:204)
	at voidious.utils.RoboGraphic$Dot.render(RoboGraphic.java:45)
	at voidious.move.<CENSORED>.onPaint(<CENSORED>.java:390)
	at voidious.<CENSORED>.onPaint(<CENSORED>.java:103)
	at robocode.PaintEvent.dispatch(PaintEvent.java:61)
	at robocode.Event$HiddenEventHelper.dispatch(Event.java:249)
	at net.sf.robocode.security.HiddenAccess.dispatch(HiddenAccess.java:195)
	at net.sf.robocode.host.events.EventManager.dispatch(EventManager.java:486)
	at net.sf.robocode.host.events.EventManager.processEvents(EventManager.java:459)
	at net.sf.robocode.host.proxies.BasicRobotProxy.executeImpl(BasicRobotProxy.java:403)
	at net.sf.robocode.host.proxies.BasicRobotProxy.execute(BasicRobotProxy.java:119)
	at robocode.AdvancedRobot.execute(AdvancedRobot.java:565)
	at voidious.<CENSORED>.run(<CENSORED>.java:48)
	at net.sf.robocode.host.proxies.HostingRobotProxy.run(HostingRobotProxy.java:250)
	at java.lang.Thread.run(Thread.java:619)
SYSTEM: Exception occurred on robocode.PaintEvent

I get this when I enable paint, but then if I restart the match, everything works and paints fine. --Voidious 05:17, 13 May 2009 (UTC)

I bet this is your new robot, isn't it? Or you need not to <CENSORED> =D I myself sometimes get BufferOverflowException, but I got it when DrawingBot overflow its renderables ArrayList. » Nat | Talk » 05:41, 13 May 2009 (UTC)

Actually I just like to use a lot of swear words in my development version class names. =) Just kidding. --Voidious 14:22, 13 May 2009 (UTC)
Then you will need to either use java obfuscater or rename them, along with its reference, to hide the swear words =D Come on, why it is so secret? » Nat | Talk » 14:32, 13 May 2009 (UTC)

Wow, the two bugs I reported have already been fixed! I guess I'll see the fixes in the next version of Robocode. RobertWalker 16:05, 14 May 2009 (UTC)

Not so surprised. If it isn't hard, Flemming will get it in one night actually. Even if it is hard, having stack trace reported along will make his life a lot easier (even the hard one I've reported fixed in 3 days, but by Pavel Savara) » Nat | Talk » 16:22, 14 May 2009 (UTC)

Complete Code

I think that we should have the completed robot code posted because for the life of me i can't figure it out. And there are newbies who won't either. —Preceding unsigned comment added by Oldtopman (talkcontribs)

Well... I'm not sure what you want exactly. A "complete robot" of sorts could be created by simply putting public class SomeRobot extends Robot { ... } around the code in the 'Simple Example' section. Could you explain what it is you feel is not explained/demonstrated clear enough? --Rednaxela 01:55, 28 January 2010 (UTC)

Question!! Shouldn't scannedX be (int)(getX() + Math.cos(angle) * e.getDistance())? In the article, sin is used... ---- urgood2 08:14, 21 March 2010 (UTC)

Well, no. In Robocode uses compass system, which zero degrees is at top and count clockwise, while in maths, the zero degrees is at right and count anticlockwise. So in Robocode, use sin for X and cos for Y, instead of cos for X and sin for Y. --Nat Pavasant 10:03, 21 March 2010 (UTC)

OK.. So how does that make us switch those two? ---- urgood2 01:33, 22 March 2010 (UTC)

If you draw a rectangle, like:

A      B
 +----+
 |   /|
 |  / |
 | /  |
 |/   |
 +----+
D      C

Let say we are at D, and enemy at B, so AC is our distance. Let make angle ADB = 30 degrees. In Robocode angle, the angle would be 30 degrees, but in normal Maths, the angle would be 60 degrees.

In normal maths, we use cos(angle), which is CD/BD. But in robocode angle, we need to use sin(angle), so it can be AB/DB. Hope you get it. Again, I am not good in explanation of Maths in English =) --Nat Pavasant 06:04, 22 March 2010 (UTC)


Thanks for the explanation, Nat. I'll try to figure it out with that. ---- urgood2 06:37, 22 March 2010 (UTC)

Contents

Thread titleRepliesLast modified
Graphics are not really mirrored, or is it just me?220:35, 15 April 2013
Debugging waves with onPaint()1102:23, 19 May 2012
Lib files on linux104:23, 11 May 2012

Graphics are not really mirrored, or is it just me?

Hello! Sorry for digging this out, but the article mentions that the coordinate system is mirrored to fit the Robocode way of coordinates. But for me, this doesn't work at all. Did recent versions of Robocode revert this setting? For me, x is okay, but y is behaving the other, 'wrong', way again.

Kenran14:47, 15 April 2013

Nevermind, I just found out that the check box changes this behaviour... silly me! You could delete this section of the discussion page, I don't really know how to do so :)

Kenran20:20, 15 April 2013
 

No need, maybe someone else with this problem will find it. =) Glad you figured it out! I thought there was a checkbox to toggle that behavior, but I didn't want to comment until I had a chance to check.

As I recall, the reason for this is that before Robocode itself had graphical debugging, someone made something called "Robocode SG" to enable it, and the API adopted by Robocode is the same except for fixing the Y coordinate orientation.

Voidious20:35, 15 April 2013
 

Debugging waves with onPaint()

I've had a problem vexing me for some time....

From what I know by reading this amazing wiki, bots fire bullets the tick after fire()/setFire() are called. (assuming one never calls them until the gun is cool) However, if I make a wave (a wave that I'm firing for targeting purposes, not a wave fired at me) with a launchTime = getTime()+1 and then draw it, my wave reliably gets drawn one tick behind the bullet on the robocode screen.. doesn't begin to break (my waves change color when they begin the breaking process) till a tick after the bullet visually hits the opposing bot.

Everything lines up perfectly on screen if I just have launchTime be this tick.. but that's supposed to be off. I don't think I'm off in my wave radius calculation:

radius = velocity*(getTime()-launchTime)

Does a Bullet move its first step on the same tick it is created?

Tkiesel13:39, 17 May 2012

Are you doing your calculating in run() or in onScannedRobot()? IIRC they happen on different sides of the getTime() update.

Skilgannon14:39, 17 May 2012

It's happening in onScannedRobot()

Generally speaking, can I use onPaint() as a guide to having my picture of the battlefield properly placed? I guess that question boils down to "Do Robocode's own graphics and onPaint() happen at substantially the same time relative to the bots/bullets progressing from tick to tick?" If so, then proper alignment of my debug graphics with the screen means I'm getting things created/updated at the right times.

When my onPaint() draws my waves, breaking waves display their current min/max precise intersection angles. It was a beautiful moment when I saw that happening, and it looked accurate right down to the pixel (or as close as the naked eye gets) on the bot's bounding box. I'm just hoping that moment of "huzzah!!" wasn't in vain.  ;)

Tkiesel15:11, 17 May 2012
 

Two important things here:

  • The bullet's fire time is the tick you call fire/setFire/setFireBullet. The following tick the bullet appears and has traveled forward by its speed once from the location you were when you fired it. The tick after you call fire is the first tick the enemy can see that you've fired a bullet. And the tick before you called fire is the last info you could use to aim, since on the firing tick, the bullet is fired before the gun is turned.
  • The order of operations is: (all other events), onScannedRobot, onPaint, run(), time increments. So if you fire from onScannedRobot, your graphics will line up. But if you fire from run(), things might look a tick behind, because they won't be painted until next tick's onPaint.
Voidious15:29, 17 May 2012

Re: "But if you fire from run(), things might look a tick behind"

Unless of course your bot is using a trick like making your "run()" code happen at the start of onPaint when onPaint is called, effectively re-ordering the "run()" code to be before "onPaint()" :-)

Rednaxela16:12, 17 May 2012
 

If you fire from run(), graphics can still line up if you also paint from that same run().

The way I do:

(all events), put all event data in a custom queue, execute() returns, cache battle state to avoid 1000 calls, process event queue and everything else in the order I want: radar, retrieve data from teammates, movement, fire gun, energy management, turn gun, send data to teammates, graphical debugging.

MN16:14, 17 May 2012

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.

Rednaxela16: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.

MN18: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-san22:55, 17 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).

MN13:29, 18 May 2012
 
 
 
 
 

Lib files on linux

Hi, I'm new to this but I'd like to use eclipse. As I look through the tutorial on how to set it up for robocode, I noticed that it was for windows. When I go to find the lib files for robocode on my laptop, their not in the same place. Does anyone know where to find them? I'm using a debian distro and installed through the included software center.

Rimp03:42, 11 May 2012

I've never installed Robocode via the distro before, but looking at this it appears that robocode.jar and such are located in /usr/share/java/ if you install that way. That help?

Rednaxela04:23, 11 May 2012
 
Personal tools
This is a cached copy of the requested page, and may not be up to date.

Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Can't contact the database server: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) (localhost))


You can try searching via Google in the meantime.
Note that their indexes of our content may be out of date.