Talk:Robocode/Graphical Debugging

Anybody else running into these two issues?

• FontMetrics StackOverflowError
• Graphics2D.setFont() has no effect

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 (talk • contribs)

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)

I sometimes open other robots' debug graphics just to see how they work, if I have some wrong calculations or just for fun but robots such as Knight, SleepSiphon and DrussGT have really really slow graphics on my computer even if it doesn't seem like they draw too much. Is it a problem with my robocode settings(I both tried with DEFAULT and SPEED) or is it just the bots which draw really slow.

I’m working on a robocode version that uses hardware acceleration for graphics. Otherwise painting is calculated by CPU and is expected to be slow. Anyway, both DrussGT and Knight runs smoothly on my machine. I just can’t turn on anti-smooth which takes forever to render one tick.

Mine is setup for speed version and I tried single, double and triple buffering and I am pretty sure that my machine is not the slowest one(3.1 Ghz CPU but yours is probably a lot faster). It is probably because of the text they are rendering.

I have a really poor machine and they still run smoothly here. Things get laggy only when in melee.

Thanks for the response, I generally have NetBeans running when I am testing my robots but I just tried it without NetBeans and it is still running with about 5 FPS.

One thing I have noticed is that low FPS only happens when a bot is rendering text. In any case, can you send me your rendering options?

Maybe just our understanding of "running smoothly" is different.=)

By smooth I mean it's at least 30 fps (or 60 fps at best). Actually those bot gets 22 fps, but still smooth enough comparing to 5 fps.

I used to notice FPS drop when text are drawn, but recently that's no longer noticeable.

note that I run robocode with these JVM parameters:

    -Dsun.java2d.opengl=true -Dapple.awt.graphics.UseQuartz=true -Dapple.laf.useScreenMenuBar=true -Dcom.apple.mrj.application.apple.menu.about.name="My Robocode"

That's really cool actually. Please keep sharing your progress on this, and you if give up on it share what you got with us, maybe we can get our hands dirty too. :)

Thanks! I'm very excited that more people is getting interested in this project. Anyway, I merely have full time during internship so the development may be slow ;) But I would like to post everything on Github asap where everyone could participant in.

Your openGL might be disabled by default. Have a look at the end of Thread:Talk:EvBot/Did any one noticed the FPS drop in robocode 1.7.3.0? discussion.

This is what I have to do on my Linux machines to get decent FPS.

Beaming thanks for your help and I tried everything with it but because of my lacking computer knowledge I didn't even know what to write or where to put it. The thing I tried was copying the OpenGL=true part and pasting it somewhere that seemed appropriate. The program worked perfectly but nothing changed about the FPS.

Btw, what JVM version are you using? It seems that some version of JVM handles text drawing poorly on mac. But I couldn't remember any details.

I'm using Oracle JDK 8

I am using JDK 8 which I got with NetBeans.

I sometimes open other robots' debug graphics just to see how they work, if I have some wrong calculations or just for fun but robots such as Knight, SleepSiphon and DrussGT have really really slow graphics on my computer even if it doesn't seem like they draw too much. Is it a problem with my robocode settings(I both tried with DEFAULT and SPEED) or is it just the bots which draw really slow.

Sorry for double post but I don't even know how did I duplicate it. Can somebody please remove it?

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.

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

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.