Darwinbots Forum
Code center => Darwinbots Program Source Code => Topic started by: Botsareus on November 27, 2010, 12:38:57 PM
-
Here are my 5 non-optional changes:
randomization seed:
Added An Input box so users can set the randomization seed manually on program startup, by default the timer is used as the seed but you can set it as well.
This makes the program easier to debug.
If you click display seed, in the chart form, the seed will be set as part of the chart forms name and the MDIforms name, this is done so if you are running two or more instances of Darwin Bots you will know what chart belongs to what instance.
Find Best:
The new findbest works by calculating which robot family has the most energy, instead of the most population.
Time limits on mutation:
The mutation system was heavily modified to stop mutating after a 4 seconds, this way if a robot has huge DNA you don't have to wait a long time for it to mutate.
MDIform form size is fixed: PLAN A
The reason I fixed the MDIform size is if you run the same simulation on a wide-screen the screen dimensions are different. The size I am using is something in-between wide screen and regular.
save mutation rates and load mutation rates:
Added save mutation rates and load mutation rates buttons to the mutation menu they are stored in a file "mutationrates.txt" in the same folder as the program .
Now you can give any robot the costume mutation parameters found by the program.
What do people think? I will start implementing them starting Monday after school but I need your opinions because I actually want these to be implemented in the next revision of DarwinBots2. I'll code them myself. I practicaly already did, I just have to recode them for DB2.45. I just realized how good my timing is (as usual. :() Apparently Panda is doing a major revision of the program too. Shall I wait for him to get done, or should I go for it?
-
Shasta is doing a bit, wait for him and then have a go.
-
Numsgil do you like my updates so far???
-
Here are my 5 non-optional changes:
randomization seed:
Added An Input box so users can set the randomization seed manually on program startup, by default the timer is used as the seed but you can set it as well.
There should be an option for this already in the options panel.
The new findbest works by calculating which robot family has the most energy, instead of the most population.
Yeah, this is a long overdo change.
Time limits on mutation:
The mutation system was heavily modified to stop mutating after a 4 seconds, this way if a robot has huge DNA you don't have to wait a long time for it to mutate.
Wouldn't it make more sense to just have a lower mutation rate?
MDIform form size is fixed:
The reason I fixed the MDIform size is if you run the same simulation on a wide-screen the screen dimensions are different. The size I am using is something in-between wide screen and regular.
There are some graphics bugs dealing with aspect ration, but they should be fixed instead of patched.
save mutation rates and load mutation rates:
Added save mutation rates and load mutation rates buttons to the mutation menu they are stored in a file "mutationrates.txt" in the same folder as the program .
Now you can give any robot the costume mutation parameters found by the program.
Sure, but wouldn't it make more sense to save and load user-named files?
-
Time limits on mutation:
The mutation system was heavily modified to stop mutating after a 4 seconds, this way if a robot has huge DNA you don't have to wait a long time for it to mutate.
Wouldn't it make more sense to just have a lower mutation rate?
Yes please. I usally set mutations to 1/32 x after adding a 0 to all default rates for a total of 1/320 x
-
There should be an option for this already in the options panel.
Can't find it...
Wouldn't it make more sense to just have a lower mutation rate?
Numsgil I have a new system in place where my mutation rates change ALOT. It is a proven system that gave me good results (It is one of my "optional" changes, yes I know, the program is complex as it is blablaba, do not care, I do not want to port my changes every time a new virsion is released...)
There are some graphics bugs dealing with aspect ration, but they should be fixed instead of patched.
Tell me how , or patch it! please! We need to figure out our screen ratio...
Sure, but wouldn't it make more sense to save and load user-named files?
That can be done, good one there.
P.S.
I got six more "optional” changes coming called "Global Special Settings" when you click the "globals" button. ;)
-
Can't find it...
It is under Options(Menu)->General(Tab)->Random Numbers(Section)->"Enable User Seed" + "Seed Value"
-
It is under Options(Menu)->General(Tab)->Random Numbers(Section)->"Enable User Seed" + "Seed Value"
ok, so the only change I am making is that the "Enable User Seed" is always enabled. And the seed value is pregenerated. Sweet, no need for no inputbox!!!
I seen this work, I use the timer as the pregenerated seed.
Now this only leaves the screen ratio, any ideas what it should be and how to fix it?
Oh, nm, I remembered why I need it as InputBox in the first place. Let's say someone loads a simulation w/o even going into settings, If I want my sim to load with a costume seed I need a prompt. Any ideas? Should a user go to the settings first and that will be treated by the program as "Enable User Seed" ? good one?
-
Now this only leaves the screen ratio, any ideas what it should be and how to fix it?
Bleh... the whole graphics system is sort of hacked together. I think if someone sat down and thought things through a little better in terms of setting up Viewports and Cameras (similar to how the graphics in DB3 is set up) the problem would automagically fix itself.
Let's say someone loads a simulation w/o even going into settings, If I want my sim to load with a costume seed I need a prompt. Any ideas? Should a user go to the settings first and that will be treated by the program as "Enable User Seed" ? good one?
Seeds are saved in the sims.
But here's an interesting problem: when you load a sim, it's not going to simulate the same as if you never saved and reloaded it, because you're resetting the random number generator. What we really want to do is serialize out the random number generator in a saved sim, instead of just the seed. But I don't really know how to do that in VB6.
-
Well, one (bad) way you could do it would be to store the number of random calls, and then call random an equal number of times on load. Really bad way actually.
-
Actually that's probably a reasonable enough idea. You should be able to power through millions of random calls in no more than a second or two, and it's easy enough to wrap calls to rand inside a wrapper.
-
Seeds:
Cool, but here is a par of problems:
I guess in the simulation structure we will also need to add a pointer of what is the current random number...
1.) What if you do not want the sim to continue in the same way?
2.) What if your sim is running long enough that we run out of random numbers? If you can give me about how much 200 hours of simulation time (10 day limit) doubles it will take, and how much ram we are consuming, then we go for it. Remember think big bc a robot with lots of dna will consume more 'randomizeddoubles' (new word :P) when it mutates.
My idea is to save a sim every minute. Then restart the sim knowing the seed if there is a crash or you need to turn off the PC. This may take a while but, If within that first minute the sim crashes then bingo: I know the seed and I can debug the sim for that minute through vb.
View point or Cameras: PLAN B
Nice, but we need a fix now, so everyone is running the same simulation across all resolution ratios, especially if we go with the new randomizer idea.
How about this: The mdiforms size will not be permanently fixed, instead it will fetch its current size and if it is maximized. Then the system will temporarily resize to the size I set for my "fix." Then after the simulation starts it will resize back to the size set by the user and a user can zoom-in if needed.
-
What if your sim is running long enough that we run out of random numbers?
Hey, Numsgil I just did a pritty sweet proof of consept:
Private Sub Form_Load()
Randomize 10 'initial seed
Dim randob(50) As Double 'only 50 for proof of cosept
For e = 1 To 50
randob(e) = Rnd(randob(e - 1))
Next
For e = 0 To 50
Debug.Print randob(e)
Next
'reloop consept (should be endless) a.k.a. next 50
randob(0) = randob(50)
For e = 1 To 50
randob(e) = Rnd(randob(e - 1))
Next
For e = 0 To 50
Debug.Print randob(e) & " is next"
Next
End Sub
All the wait time will be only when the simulation starts, and when we have like 500000 doubles instead of my 50...
-
1.) What if you do not want the sim to continue in the same way?
Then you load the sim and change the seed. If you really want to have a way to override the saved seed, maybe we can play with command line options?
2.) What if your sim is running long enough that we run out of random numbers? If you can give me about how much 200 hours of simulation time (10 day limit) doubles it will take, and how much ram we are consuming, then we go for it. Remember think big bc a robot with lots of dna will consume more 'randomizeddoubles' (new word :P) when it mutates.
You can't run out of random numbers. Random number generators just end up repeating if you go too long (known as the random number generator's "period").
I don't have performance specs, but random numbers are simple enough that I imagine you can generate tens of thousands to millions per second. Since you'd only have to do that when you load the sim, I imagine it shouldn't add more than a second or two to load times. Might be a reasonable way to get something working, anyway.
My idea is to save a sim every minute. Then restart the sim knowing the seed if there is a crash or you need to turn off the PC. This may take a while but, If within that first minute the sim crashes then bingo: I know the seed and I can debug the sim for that minute through vb.
Sure, a reasonable enough goal.
View point or Cameras:
Nice, but we need a fix now, so everyone is running the same simulation across all resolution ratios, especially if we go with the new randomizer idea.
The aspect ratio is a display bug only; it shouldn't affect the simulation at all.
-
The aspect ratio is a display bug only; it shouldn't affect the simulation at all.
It will not affect a simulation.
It will affect "the" simulation when you start a new one...
:sleepin:
And I thought college will be the thing that will tire me out this week.
-
The aspect ratio is a display bug only; it shouldn't affect the simulation at all.
It will not affect a simulation.
It will affect "the" simulation when you start a new one...
What?
Are you talking about the simulation size or the aspect ratio of the graphics?
-
Numsgil, here, look:
(http://img41.imageshack.us/img41/9173/dbwork.jpg) (http://img41.imageshack.us/i/dbwork.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
If I press "Start new" the resulting simulation the way it is setup above will always be a square…
-
The display and the underlying simulation are separate.
For instance, I assume you know you can zoom in and out with the magnifying glass icons? That only works if the display is separate from the simulation.
Try spamming the zoom in, zoom out, and lock/unlock icons. When you see a tiny white square in the top left corner that's a good indication that the display is borked (that white square is the simulation extents. You're waaaayyy zoomed out).
-
Tryed it. Same thing.
One good way of knowing is, If you do what I did above and insert like 5 blank robots, look how they position themselfs.
(http://img109.imageshack.us/img109/1161/dbwork2.jpg) (http://img109.imageshack.us/i/dbwork2.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
And if I started this one wide then the result will be wide...
(http://img442.imageshack.us/img442/5350/dbwork3.jpg) (http://img442.imageshack.us/i/dbwork3.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
All I am doing is clicking the species tab first, and then start new...
BTW: With my planB I am not sure if I can resize a MDIForm to be bigger then the desktop...
-
Bleh, you're not understanding.
Okay, imagine there's a square simulation, with the simulation extents of like 2000x2000.
Now imagine you draw it. If the aspect ratio is wrong, it will be drawn as a rectangle. The underlying simulation is still 2000x2000. The bots see it as 2000x2000. But you, a human, see it as rectangle. Because of the way graphics are drawn, circles will still look circular, but they won't match up to the physical reality of the actual simulation (which from your point of view would be ellipses).
There's some code somewhere that can sort of reset the aspect ratio, but it's buried right now in the lock/unlock or zoom in/out code, and it's conditional on the state you came from and the state your going to (eg: try zooming out from a "locked" display that's zoomed way out). Which is why it should fix itself if you can spam those buttons in specific order I don't remember.
-
I think we should simplify the heck out of this one.
We need to have fixed ratio for our simulation and it should draw in that ratio... If anything add a scroll bar or zoom out...
ex:
If the simulation is a rectangle and the mdiform is a square it should display border limits on the top and the buttom, or a scroll bar across the buttom.
Now that I realise how crazy complicated this "aspect ratio correction" code is, I am not touching it, so I will do my PLAN A fix until someone can sit down and really fix it. :wacko: However, I might look into adding vertical zoom in, zoom out buttons. And horizontal zoom in , zoom out buttons. I will also look into resetting the paint area to fit with the mdiform if the mdiform gets bigger.
-
Numsgil, I just tried to separate the zoom algorithm into X and Y zoom algorithms without any luck. You are right, the system "stretches" the simulation to fit it into the screen ratio. As of now I am leaving this code alone.
Sorry for the misunderstanding. This concept was confusing for me, imagine how confusing it will be for a new user, I suggest you add a wiki on this subject to make sure new users are not confused.
-
Sorry for the misunderstanding. This concept was confusing for me, imagine how confusing it will be for a new user, I subject you add a wiki on this subject to make sure new users are not confused.
It's only confusing when it's not working right (or you're looking at the code, haha).
Intuitively we have a good understanding of how it should work: it's like a video microscope. You can move around (translate) and zoom in and out, and independently of that you can also enlarge the screen size and move the window around on your desktop.
The problem is that coding it to do that correctly requires handling a lot of Windows events and working through the math. I've got it working fine for DB3 with the various Viewport and Camera classes, so if someone wanted to take a stab at redoing the graphics side of DB2 to do something similar it should work pretty well.