CassiusClay/GLOldVersion

This article makes references to graphical capabilities enabled by RobocodeGL, an add-on to Robocode developed by David Alves. Current versions of Robocode include native (Java Swing) graphical debugging capabilities, and most everybody now uses those instead.

Sometimes when a bullet hits CCGL, and graphical debug is on, Robocode locks up for a few minutes (!). In the first frame rendered thereafter there are many big blue dots, of which the edge is very smooth, not like many )'s on top of each other. I hope it doesn't try to render a million (or so) of them? -- Jonathan

Is this when a bullet hits or when a wave hits? I've noticed a flicker when the wave hits. Not that everythings stops though. But this is a problem with RobocodeGLV014 that if you draw too large objects, it starts eating resources. Sometimes I've managed to put my entire machine to a complete halt.... Your observation might point on a bugin CC though. Maybe the danger values get too large at close range. Thanks! -- PEZ

I just ran it again, but this time with statistics. RAM usage increased with over 10 MB per second! It begins to run slow when the 'real' RAM is full, particularly when a wave hits (hangs for a very short period). When a bullet hits it can hang for minutes, but ONLY if graphical debug is turned on. Strings are still drawn when it is turned off (reported twice in RobocodeGLV014/BugReporting), so I suspect the dots. -- Jonathan

I suppose I could write smaller dots. Problem with that is that it's hard to see the peaks in the wave when it's at far ranges then... -- PEZ

Can't you just put a fixed limit on them? -- Jonathan

That would make all dots exceeding that limit equally large. But maybe I can skip the bullet flight time weighting for the GL graphed dots. That would solve the issue and also make all waves "readable". -- PEZ

It doesn't even need to have to do with the dot size. I mean, why would it need hundreds of megabytes (it does after after a few seconds) just to draw some bigger dots? I think there should be something else... The best way to find out is to set the limit at 1 pixel, and then watch your RAM. -- Jonathan

Well, I don't know why it needs tons of RAM when the dots get big. But it does. Try increasing the dot size and you'll know. -- PEZ

Just tried it myself. You're right. Btw, if you set the size to 0 it is even worse... -- Jonathan

PEZ, Are you re-using your dots in some fashion or are you initializing new dots every tick? If you are re-initializing (which is slow and what DH currently does) then perhaps you are leaving the old one out there in a fashion where they can not be reaped? I have not looked at the code (I am still in California and on a dialup 33K connnection of all things) so this is a very wild guess. When I get home I plan on releasing my RCGL version of DarkHallow too. -- jim

I'm reusing the same dots throughout the waves travel. Just moving the dots around. It's really about the size of the dots. Write one dot large enough and it will display very badly and things slows down a lot. It's a bug in some GL layer probably. -- PEZ

If you disable smooth points everything is fine... it is enabled in GLRenderer. If you want all dots to appear as non-antialiased squares, just remove that line in GLRenderer. If you want to use squares at size>x, you can do that in PointGL. -- Jonathan

I'm not sure i understand... Should I hack GLRenderer? Well, good to know that option exists. But it's interesting that you edit this page today since I just put together a new GL version of CC. Which doesn't have the above problem. It's full of other irrelevant debug code though. I'll clean it up and upload it later tonight. -- PEZ

It isn't very hard to change the smooth points in RGL. In GLRenderer.init() you just have to remove the gl.glEnable(GL_POINT_SMOOTH); line. You can also glEnable and glDisable it in any draw() method, so you can easily disable it when size>x (keep in mind that you should use gl.GL_POINT_SMOOTH there!). -- Jonathan

This is what you get if you set the threshold in PointGL to 20:

http:/robocode/uploads/jonathan/dangerouswaves.png

Doesn't look good, but it's better than crashing. Note that the waves which are very close to each other are caused by skipped turns (I think), which are in turn caused by rapidly pausing/resuming when a wave hits to be able to capture it without going down to 1 fps. -- Jonathan

I recently started playing with GL (great stuff!). The extreme memory consumption is caused by blending (edit: not. I really thought I saw that making the difference...). I wrote a simple app rendering dots in a circle. It's funny that drawing 16384 smooth dots of 50 pixels (size of window content: 800*800/16) takes far less memory than drawing 4 such dots. You have hopefully noticed that antialiasing and performance don't get better when you draw 7 50-pixel antialiased dots per pixel. ;-) -- Jonathan (still around here... a bit)

I have no clue what you are talking about. But the new version of CCGL doesn't have a performance problem like this one anyway. -- PEZ

Still talking about large points, which are not specific to CCGL or Robocode at all, but are related to this page. ;-) -- Jonathan