User talk:Chase-san/Roboflight/Archived Talk 20130214

Well if anyone has any suggestions, I am open to them. My classes are finished up. --Chase 21:34, 21 May 2010 (UTC)

It is still missing a lot, the rules here don't exactly cover it perfectly. I have some of the missile system written. and a lot of the robot api. (I in fact moved my robots outside of this to use the api). I included the source as well. It is probably getting a little messy, but I have javadoc and comments (many wasteful ones in older classes) in there. JOGL Libraries Core Test 3. For those who cannot get it to run (for whatever reason). It currently looks like this.

http://www.csdgn.org/files/images/rfscreen.gif

--Chase 19:07, 9 June 2010 (UTC)

It seems that you forget to pack the resource/sphere32.obj. I got FileNotFoundException! --Nat Pavasant 11:49, 10 June 2010 (UTC)

Whoops, those are important. Added, they are in the same place. Sorry about that. Other news, I am currently writing the collision system (Fun!). --Chase 16:29, 10 June 2010 (UTC)

I noticed I had a lot of dead code, poorly designed classes, and things that cannot possibly work strewn through the code. Basically a great deal of my laziness is showing in the code. So, I am refactoring it a bit. After I am done with that I might make a source forge repository for it. --Chase 14:41, 12 June 2010 (UTC)

Please no SourceForge -- it is REALLY slow =) Google Code, BitBucket or GitHub is around 10x faster than SF.net --Nat Pavasant 14:59, 12 June 2010 (UTC)

I might have a look at Google Code. I don't feel like dealing with GitHub's SSH key insanity. BitBucket I don't have Mercurial built into eclipse (yet). Anyway I have done away with the old object rendering method (which is really slow) and replaced it with vertex lists (but not VBO, JOGL doesn't seem to like to play nice). I decreased the near clipping plane. Rewrote the peer system and the way the missiles work. I also (finally) added a texture to the robot model. I may yet replace the current model with a better one however. Though I am trying to avoid using too many polies. If someone else wants to make a 3D model for it, all it needs to be is obj and under say.. 1600 polygons (current ones are around 800ish). --Chase 20:37, 12 June 2010 (UTC)

After a bit of poking, I decided to use BitBucket. Mercurial doesn't seem that bad, and has an Eclipse Plugin. http://bitbucket.org/chasesan/roboflight --Chase 20:08, 14 June 2010 (UTC)

Well, I have a working version here. Whats new, off the top of my head... Classloader (that surprisingly works), basic collisions, missiles, bullets, battle start (you can only start one yet). Selection pane, and you can even include try your own robots in it now (see classloader above). Many of the core bits of the robot are still not in, or rather not back in (as I removed them for refactoring). Random starting locations are also, not in yet. (no real battling can be done due to this and lack of robot/bullet robot/missile collisions).

On the subject of collisions, the sphere sphere collisions I am using are nice, neat, and fast. However sphere box collisions are not as much so. So this leaves three options. Make robots have a spherical bounding box, change the bullets and missiles to use Orientated Bounding Boxes, or Find a more efficient collision system for them. (a sphere oriented ellipsoid would work, if I could figure out the math).

Core Test 4 JOGL Libraries

--Chase 06:23, 21 June 2010 (UTC)

A new core build is done, all collisions but robot/robot collision is done. I finally got around to refactoring the text, it is much better now. The program suffers a few lags here and there, not sure why yet (at least it does on windows). Missiles don't yet have an explosion radius, but they do damage when they hit. As do bullets. Bullets and missiles can collide. With each other and others of their own, they die when they hit. You cannot yet collide with the edge of the outer sphere, this will be simple to fix. Energy doesn't regenerate yet, but it will soon. There are so many TODO's in the source code, which still need to get done. So forgive me for not getting all the 'most important' things done yet. Actual rounds and how scoring will be done needs to be decided soon. I also need help in figuring out how to load multiple instances of the same robot.

For the most part the game is nearing the 'usable' stage, and thus alpha. The next build will probably be Alpha. I am still using bitbucket, and I have been updating it.

Please tell me what you think so far.

Core Test 5 JOGL Libraries

— Chase-san 21:49, 25 June 2010 (UTC)

I think that the lag you mentioned is caused by Java GC. I think it is quite good, but I'm not sure how to hit each other (your samples can't hit each other =)). But I think I found some bugs. When I start first battle, I choose two Simplex. Only one is put in the battle. So I start new battle with one Simplex and one Rotator, but two each appeared (4 robots) in the battlefield. Cheer! --Nat Pavasant 04:47, 26 June 2010 (UTC)

Yeah, I knew about that bug. Two of the same robot cannot be entered, when I get that fixed it should also fix the problem with the new game. As for the samples hitting each other, Simplex actually can, and will hit a stationary target. However, Rotator isn't stationary, so it usually misses. Rotator just shoots randomly and it sometimes gets lucky and lands a hit on Simplex with a bullet. I suppose I should make a sitting duck like sample. — Chase-san 15:41, 26 June 2010 (UTC)

I'm pretty sure the lag is not the Java GC.... I just tried it and ran into memory used by the system memory use exploding out of control and for some reason it wasn't being freed for program memory, then forcing the machine to swap wildly and nearly lock up. I'm pretty sure the cause of that here is the same as the cause of the lag there. Given how I wouldn't expect this from normal Java code and that it was not normal program memory, I'd suspect something is going terribly terribly wrong in the opengl code. Note, this doesn't occur here in Core Test 3. --Rednaxela 16:47, 26 June 2010 (UTC)

That is very informative, I completely ignored memory usage since I was using Java. Usually resolving memory leaks is only something I need to do in C/C++. Though there might have so memory that is being held onto for some reason in the Java sections. Core 3 was before I refactored. So I will examine the difference between Core 3 and Core 4/5. See if I can figure out where the leak is. — Chase-san 17:37, 26 June 2010 (UTC)

Well just to clarify, it wasn't memory held by the java process, it was memory held by the kernel or something I think, thus I'm pretty sure isn't a Java memory leak, but more like some opengl resources that aren't being disposed of properly or something. --Rednaxela 17:52, 26 June 2010 (UTC)

Yeah I just noticed that, while monitoring the Memory used by the runtime. I will take a look at the GL code, it might be the vertex lists that are causing the problem. (which I didn't use in core 3, but are only in core 4 and 5). Strangely the runtime only uses 16 mb when run from Eclipse, and about 60 mb, when run standalone. — Chase-san 18:01, 26 June 2010 (UTC)

Turns out is 'mainly' from the Text system. Other factors may attribute to it as well, but for the most part, it is the Text. I am fixing it now, I kinda already knew the way I was doing it was going to be a bad idea. But I just wanted everything to work first. However I didn't think it would produce a GL leak. Live and learn. — Chase-san 18:50, 26 June 2010 (UTC)

Alright Core 6, this one I got a lot of the 'core' features done in. Obviously I fixed that resource leak. Its not perfect but it never got over 200 since I fixed it (it otherwise just kept rising and rising). I also made it detect minimize and to stop rendering, to save CPU time. No speedup yet. Robots die now. You can also have multiples of the same robot, since every robot gets loaded with its own classloader now. I fixed a number of bugs here and there, I cannot remember all of them. I added a few more sample robots. But when it comes to writing sample robots. I am not all to good at it. The only things that need to be done before Alpha is having multiple rounds, giving the missiles explosion radius, robot/robot collision, and updating the title so it no longer says 0.2.

Also please remember I do have this on bitbucket where you can view the source, file bug reports and so on and so forth.

Also to save my poor slow Internet connection I have split things again, into jogl, resources and main package. One more thing to download, but you should only need to every time those are updated (which is not often).

Core Test 6 Resource Files JOGL Libraries

— Chase-san 21:20, 26 June 2010 (UTC)

Note, on the memory thrashing, I found calling the garbage collector every tick keeps it nice and tightly around 80 mb, however, this also leads the game to be very slow. This makes some sense, since OpenGL is not part of native Java. There is a huge number of incompatibilities and so forth that I have needed to address with OpenGL, this just being the latest. So in this case, I have done my best to balance garbage collection and performance. I don't call it every tick, and it has its own thread (rather, it uses the main threat, which does very little). As long as there isn't to much on screen (20 or so robots is fine), it does a decent job. — Chase-san 02:19, 27 June 2010 (UTC)

Some other misc thoughts:

• Perhaps it would be nice to have cameras that follow each robot?
• Perhaps some architecture should be shared with normal Robocode? I mean, the sandboxing, repository management, and rumble code, is all a lot of work to get right, and I'm sure lots could in theory be shared, at least if there was some refactoring.

--Rednaxela 04:15, 27 June 2010 (UTC)

It is possible I suppose.

• Robot following cameras are actually already in the planning stage! Unfortunately I haven't decided how switch cameras yet.
• I planned to 'borrow' Robocodes security manager, once that became an issue.
• Not sure what you mean by repository management (the robocode repository was last updated in 2006).
• The rumble code could probably be modified to work once I get scoring working.

But there is a great deal of work to do yet. So these things are on the to do eventually list, unless someone else cares to do it.

I am very interested in other peoples opinions on how things should work, specifically Fnl's, since I discussed this idea with him at length.

I would also like to eventually replace my current rendering system, however every other one I look at is much heavier. The best bets is Java3D. The vecmath library in this is based on, but is not directly compatible with the one in Java3D. The Java3D libraries are also much larger. That will not be much of an issue if I have people download those themselves (they have a handy installer version). The main problem with switching now is, I have no idea how to use Java3D.

— Chase-san 05:49, 27 June 2010 (UTC)

A release isn't ready, but on bitbucket there is a version with robot following camera, improved and strangely familiar UI, and round functionality. I just need to do missile explosions and robot collision and alpha should be ready. — Chase-san 09:24, 27 June 2010 (UTC)

Robocode's repository I think means the part that manage robots installed in your local Robocode installation, which is in net.sf.robocode.repository package. --Nat Pavasant 10:46, 27 June 2010 (UTC)

Yes, that's what I meant :) --Rednaxela 15:18, 27 June 2010 (UTC)

Well, my thought is that rather than just 'borrowing' one part like the security manager, there's a lot other infrastructure that would make sense to be shared. It seems to me that most things could be common unless they are 1) physics of it, 2) battlefield rendering, 3) robot classes/interfaces. At least with some refactoring, I'd think quite a substantial amount of code could be shared. Of course, the question of how much refactoring could be sticking point for some aspects. --Rednaxela 15:18, 27 June 2010 (UTC)

I understand what your saying. However robocode is very large, and while very compete as well. A fresh start may actually produce a better end result, since it is not flavored by the way things have always been done. I understand the sharing of infrastructure, and if pursued could have the 'final' product done in a much shorter period of time. As a side note, the repository in Robocode has problems on my system (it duplicates development bots).

However while Roboflight is still small and 'light' enough to be refactored rather easily, having already do so more than once. I just want to get it done and working. Rather than spend another month with it stuck in limbo.

I have nothing against other people working on such a combining of the programs, however, as I have stated this already on multiple occasions. It does not look as though anyone else wants to get involved in doing so. — Chase-san 18:58, 27 June 2010 (UTC)