Darwinbots Forum
Code center => Darwinbots Program Source Code => Topic started by: Ammeh on January 06, 2011, 12:28:22 PM
-
:blink:
No, really. Converting procedural code into object orientated.
Somebody want to lend a hand?
Also, if we could get a SVN set up for it, that'd be sweet.
-
This has actually been something on my mind for a long time (Mainly because Java is my native language); I'm not too great at programming UI and I/O stuff, but would be glad to lend a hand at anything else.
-
Honestly, there really isn't a great reason to make a Java version of DB. DB2 sucks to work on, yes, but if you just copy it, the same problems will remain no matter what language it is written in. I have been a bit MIA the last month, but I will get the next version out at some point :dry:
DB3 would be a much better place to focus any development effort towards a new version of Darwinbots. C# is similar to Java, but in many cases I believe it is a much nicer language. C# can also be cross-platform through the Mono project and with the modular structure of DB3 this should be too hard, and is something I'm willing to look at in the future.
-
DB3 isn't finished though :| Plus I think we can pretty much ignore most of the code of DB2 and rewrite it.
the reason I say java is that it doesn't require messing about with to work on other OS's. Mono is nice and all, but I'd rather not have to install a bunch of libraries to make one thing work. Pretty much everybody has java.
-
Well, it looks like DB3 is nearing completion (The last post I see in the forum was in November when Nums was messing around with graphics); I'm willing to wait a few months before a new project is started. In the meantime, I'll just quietly stalk the forum...as always... :D
-
My 2 cents:
I attempted a C++ port a few years back. From that experience, I can tell you that most of the problems in the current DB2 source are a product of the source code itself and the way it's architected, not the language (though the language certainly isn't helping things). Also, while the core engine routines are easy enough to translate, there is extensive UI code (thousands of lines worth) that is not at all easy to translate to anything outside of VB itself. Some of the code in the darker recesses is even a mystery as far as why it's there and what it's doing. Even moving to VB.NET is prohibitive (at least 3 different coders (myself, Eric, and someone else I think...) have tried it and given up), and that's about the closest modern language to VB6 around.
It's so tempting to think that if you rewrite the source in another language (probably one you're comfortable with) it'll be cleaner and easier to work with. But the reality is that what makes the code unwieldy to work with are bits that you just can't really rip out or smooth over easily regardless of the language. Graphics routines reach into robot memory, everything is global, there's no clear separation of duties, every UI widget has custom code somewhere that connects it to the relevant member of simopts, etc.
But I went through this exact same thought path myself when I tried to port to C++, so I can't be too judgemental :P But first hand experience and general programming experience from work all tells me that trying to move this monstrosity to another language in its current form is a mistake.
If we really wanted to move the current DB2 code to another language, because maybe suddenly all VB6 apps in the world stopped working or something, here's the path I would recommend (it's boring and not sexy at all, but there is no doubt in my mind that it's the best way to approach the problem):
1. Refactor the current VB6 code to be clean.
2. Make sure it still works the same as before.
3. Now port it.
Doing #1 sort of breaks the need for #3, though (which is why it's boring and unsexy), and doing #1 well involves knowing VB6 very well, which again breaks most of the need for an actual port. But a good analogy: when you move houses, you put stuff in boxes instead of trying to move things individually.
-
I'm a little drunk, so this might not make that much sense. I'll revise it if it's unclear.
What about if we draw a flowchart style thing of what DB2 actually does. Like, in general, what's processed. In each of those processes, what happens? etc etc
Then build the program again from scratch.
Less porting the code, more porting the function.
-
More or less what I was thinking - copying the features of DBII, creating a framework and them building everything from scratch...in fact, I thought that was what you meant in the first place...
-
At that point, what actual advantage do you gain over helping with DB3 though?
If you want to work on a new version I can setup a new SVN repository and what not, that takes all of 2 minutes; but do we really need another version of Darwinbots?
-
I suppose not, but I'm more comfortable in Java and looking at a whole pile of code in a foreign language made me feel a little overwhelmed. Plus I'm too lazy to download a C# dev kit for mac :glare:
-
Clicky (http://www.mono-project.com/Monodevelop).
Just saying... don't let that stop you.
-
OT (but that hasn't ever stopped me or anyone else on this forum): eta for db3?
-
Alright, I'm convinced. Working on DB3 would be better than wasting my time in java.
I reckon we should set a deadline and really get it going though. like, 6 months tops to get everything together and have a working version to show...
-
OT (but that hasn't ever stopped me or anyone else on this forum): eta for db3?
I'm a few weeks (IRL time, assuming my current pace) from finishing what I need to finish with the Math stuff ('Azimuth'). Then I can start on the physics engine ('Lodestone'), which has some stuff already. I've written a few physics engines in my time, so I could probably pump out a working version in maybe 50 man hours (say, 2 months real time). Then graphics still needs work. I don't have a good handle on how much work is left, but certainly a few weeks at least. Then we can start on Darwinbots proper and tie it all together and get bots moving on screen. I didn't really do any work on Darwinbots between like last February and October, so there's still a fair amount of work to be done.
I reckon we should set a deadline and really get it going though. like, 6 months tops to get everything together and have a working version to show...
Problem is that it's hard to judge in terms of 'real time' since I usually can only work on Darwinbots on weekends (it's really hard to come home after staring at code at work and stare at code some more :P), and even then sometimes I'm just not in to it and play games instead :P
If people are getting to a point where they have time/effort to spare for DB3, though, I can start delegating some tasks. But fair warning: I'm not sure any of it is very fun or interesting. Or the parts that are fun and interesting are also extremely technical so you have to be dedicated enough to probably go way outside your comfort zone and read dozens or hundreds of pages of stuff before you even touch the code (I'm thinking specifically shader work in graphics. It's not hard, but if you have no idea how a graphics card actually works and how data gets pipelined it's easy to get lost).
Anyway, I'll see if I can't put together a roadmap and log some issues in Mantis and then I can start posting tasks and interested people can take them and run with it.
-
I can help, that'll get it out quicker, maybe... :p
-
I'll try to post a list of open tasks later today/tomorrow. In the mean time for anyone interested, check out the wiki page (http://www.darwinbots.com/WikiManual/index.php/Darwinbots_3) to get the code locally compiling (an important first step).
-
Kept meaning to post this but got distracted.
Anyway, this issues list (http://www.darwinbots.com/Mantis/view_all_bug_page.php) is how I'll be tracking open issues in DB3. I'll be adding new issues as I think of them. But if someone sees something there they want to tackle, let me know.
-
I reckon I probably get a web interface for Azimuth going... Let me see what I can cook up.
-
Note how the issue you picked has a child. ;) The web interface to Azimuth requires Mono to be installed on the server, which is currently not possible.
-
I thought we (I?) had actually installed mono not so long ago...
-
I just checked again, Mono is not currently installed on the server. The repositories have been down for openSUSE 11.0 for several months now.
-
I gave you an account Sammeh and assigned you the calculator part (I think it'll spam you with emails with instructions about how to log in, etc., but let me know if it doesn't). Probably what makes most sense is to set up an aspx page locally and get it working, and we'll worry about the publishing ("going live") aspect of it later. Something in PHP might work, but I imagine interfacing with .NET assemblies is difficult since it probably involves some marshaling, so probably doesn't make sense to go down that route.
I'll try to remember to be on IRC and/or skype tomorrow, though our timezones are a bit incompatible so there's probably only a few hours in the morning (from my perspective) where I can be useful. Anyway, I'll try to check in a web project under Azimuth and set up project paths and stuff (which are a whole can of worms I don't really want to get into) and write some instructions here on meta stuff like which solution to run, which things in Azimuth to connect up, etc. The rest you'll just have to play around with and google and stuff.
-
I created a project for this. You just need to open Azimuth.sln and look for OnlineCalculator. It's set up as an aspx project.
-
Alright cool :) I'll get cracking on learning how to ASP.NET and setting shit up then :)
-
Let me know if you need any help getting started. I've done a bit of ASPX work at work.
-
Refactor the current VB6 code to be clean.
Good luck with that one :P