next »

[Core Xii]

If you could find the solution using random inputs in a quicker time, then the genetic algorithm would have been a failure.

Randomness is half the evolution. In the beginning when the evolving Marios are clueless, feeding successful random genomes from the control group to the evolving group would significantly speed up the initial learning. Later on, random searching is unlikely to find better genomes than the ones evolving, so what I'd do is move Marios from control to evolve, permanently, such that whenever a Mario is moved, the size of the control group is decremented and the size of the evolving group incremented. This way, early on the randomness feeds the learning and later on, doesn't slow down the processing.

What I've seen other evolvers do is begin the evolution with a pool of random genomes. In some evolutions all 1st generation genomes are randomly re-rolled if they die. Basically the same outcome as I described above, without a separate random pool.

The only other thing I can think of is that the graphics driver is overriding my apps settings.

Ahh, you are correct. I've set my driver to override application settings for always vsync with triple buffering. Very few evolvers are graphical, so it's never come up before.

[PleasingFungus]

If you could find the solution using random inputs in a quicker time, then the genetic algorithm would have been a failure.

Randomness is half the evolution. In the beginning when the evolving Marios are clueless, feeding successful random genomes from the control group to the evolving group would significantly speed up the initial learning. Later on, random searching is unlikely to find better genomes than the ones evolving, so what I'd do is move Marios from control to evolve, permanently, such that whenever a Mario is moved, the size of the control group is decremented and the size of the evolving group incremented. This way, early on the randomness feeds the learning and later on, doesn't slow down the processing.

Core, you're missing the point. The control group isn't meant to help the genetic algorithm. It's meant to act as a... control group.

Oddball, this is really cool! Have you seen the Evolution Chamber for SCII? It's doing similar things, but somewhat more applied.

[Raptor85]

Dunno if you saw, but
http://hackaday.com/2010/11/05/ai-via-super-mario-evolution/

[Core Xii]

Core, you're missing the point. The control group isn't meant to help the genetic algorithm. It's meant to act as a... control group.

I don't see how my method lessens the effect of the control group in any way. You still see if the evolution is actually working by looking if the evolving group is acting similar to the random control group; I.e. randomly.

[nekosune]

I was using the picture one, and after a day or so, it jumped so the one on the far right, was EXACTLY the one I gave it on the far left, the one in the middle is still a hazy indistinct version, unfortunatly me being an idiot, used a well adult picture, so can't really show it what happend. but it basically is showing the exact same picture as the source

[PleasingFungus]

...so what I'd do is move Marios from control to evolve, permanently, such that whenever a Mario is moved, the size of the control group is decremented and the size of the evolving group incremented...

If you move Marios out of the control group (and into the test group), you're lowering its effectiveness. The point of the control group isn't to see whether the test group is 'acting randomly'; it's to see if the genetic algorithm approach is any more effective than just random button-mashing. As Oddball himself put it, "The control population are to see if given the same amount of time random input can do any better than the 'genetic' evolution." So, you take the same exact number of Marios, put them in the same situation, and only vary the input. That way, it's a fair test.

Copying Marios from the control group into the test group could be a valid approach, especially initially. But that's a different matter.

I'm not sure that a control group is really necessary for this program either way, though, so... not that big a deal.

Also, what on earth is nekosune talking about? At first I thought he was a spammer, but he'd be a really crummy one if so. No spam links, no spam signature. Maybe he's trying to infiltrate the forum first and win our trust...?

[bateleur]

Also, what on earth is nekosune talking about? At first I thought he was a spammer

She's talking about the picture evolving algorithm on this site, which was linked from the first post of this thread.

[nekosune]

I was using the version the OP said he had made like that one, the one available for download from the first post in the thread. And sorry if I sounded spam like :-S

[Oddball]

That is bizarre nekosune, and I have no idea how that is even possible. The polygons are rendered to a texture before being displayed in the window alongside the original, but still I can't envisage any way the texture could get replaced by the original image. I am amazed and stumped.

[nekosune]

May I PM you the link? I do not wish to post it here due to my stupidity with the starting image.

[Oddball]

Sure. I'd be interested to find out what is going on there.

[Geti]

I get scary things after updating wine, so I'm assuming it's wines fault, but though the functionality is still working, I only get to see the results when they decide to flash on screen once per generation. The whole thing stutters all over the place graphically.
It'd be awesome if someone else could test it with wine to check and see if it's a config error my end or wine that's at fault.

[Raptor85]

I get scary things after updating wine, so I'm assuming it's wines fault, but though the functionality is still working, I only get to see the results when they decide to flash on screen once per generation. The whole thing stutters all over the place graphically.
It'd be awesome if someone else could test it with wine to check and see if it's a config error my end or wine that's at fault.

works fine for me on WINE 1.3.0, no errors in console.  Do you have directx installed natively in WINE? that can screw up a LOT of programs and is in general a really bad thing to do. If you need it for other programs, you can make a new clean instance of wine (updating between versions any libraries like directx you manually installed will still stay) in a new folder, to not mess with your other apps, by doing WINEPREFIX="/path/to/the/new/directory/must/already/exist" wine tmg.exe

[Geti]

Or alternatively only set it to use the native .dlls for things that require them and use the same wine installation with the built in features of wine that let you do that for both. Tried it with and without directx. Both stuttering like crazy fools. It worked fine before I updated everything though, so it's very likely some issue my end.

[nekosune]

PM'd the link, will be intresting to see what make of it to be honest o.o I suppose could have been a one in a trillion chance.