Crazy Ideas

Jump to navigation Jump to search

Crazy Ideas

Edited by author.
Last edit: 15:08, 22 March 2013

First, we initialize integer to 255 to save a byte. :)
Then, in the PM code we use (integer = integer >> 1), instead of (integer = integer - 1).

If I'm right (which I rarely am), this would be smaller, faster and smarter. How does it sound to you?

Sheldor13:51, 22 March 2013

Sounds good. I did a geometric reduction of the key length in Toorkild as well, and it worked fine.

Skilgannon13:58, 22 March 2013

Hmm, for some reason, under Jikes, both of those changes add a byte of codesize. Any number above 127 takes an extra byte, and >> is one more byte than --

Skilgannon16:13, 22 March 2013

Were you using Jikes when you compiled Toorkild and got the weird savings from 255?

Sheldor16:35, 22 March 2013

Yes, but I was using it for an array size, so that might have been something else happening.

Skilgannon17:15, 22 March 2013

So, if we do it just like Toorkild and use 64 as the initialization value, and use integer /= 2 instead of --integer, we should break even at 249 bytes, right?

Also, I think we should try using power-3 bullets, or at least go back to power 2.6667. I think 2.33333... is a little too soft for a bot with such an aggressive movement.

If the changes work, then go ahead and release version 1.0.4.

Sheldor18:23, 22 March 2013

integer/=2 takes an extra byte from --integer, but if we switch our bullet power to 3 we have that byte to spare. I'll package it up and release.

Skilgannon18:43, 22 March 2013

Huh, for some reason it lost a lot against weak bots. Do you think this is because of the PM change, the bullet power change, or the movement change? I doubt it was because of the change to the random multiplier, because the RM shouldn't even be activated against weak bots.

Sheldor21:39, 22 March 2013

I think the higher bullet power made it waste energy quicker, giving it an extra loss or two, which pushed a bunch of bots over into the random movement instead of orbit/oscillate.

One thing I noticed while watching battles was if it starts from very far away it does loops instead of settling for a nice orbital movement. I'm thinking of decreasing the turn amount caused by the distancing, especially as it isn't as sensitive to that now that the gun can handle any distance correctly.

Skilgannon22:02, 22 March 2013

Okay. Let's change the BP back to 2.33... and the constant in the distance controller from 2500 to 3000.

We also might try doing 3/orbit + 3/oscillate + 94/random instead of 2/orbit + 2/oscillate + 96/random.

Sheldor23:57, 22 March 2013

One step at a time, I'd rather have less sacrificial rounds against top bots and lower the bullet power, although that gets us right back to where we were. I also want to see where the threshold is, so how about BP 2.666?

Skilgannon08:15, 23 March 2013

Sounds good.

Sheldor14:19, 23 March 2013

I have another crazy idea that would allow us to get rid of the distance variable. The problem is, it would cost about ~2 bytes in other areas. Should I try it?

Sheldor17:26, 2 April 2013

Of course, give it a go. I'll see how it compiles.

Skilgannon23:36, 2 April 2013

Sweet, that saves 3 bytes, down to 246. I'll package and upload in the morning when I'm a bit more awake =)

Skilgannon00:38, 3 April 2013

Ok, that doesn't work because the absoluteBearing has been fully initialised and doesn't just use the e.getBearingRadians() value, so it goes in circles. Oh well, I was hoping for some more codesize there!

Skilgannon20:26, 3 April 2013

Try it again with a pair of parentheses around e.bearing + heading. That should fully initialize absolute bearing. If it doesn't, then there must be something else going on.

What were you planning to do with the extra space?

Sheldor21:21, 3 April 2013

Nope, the problem is in the distancing, see the change I made that fixes the behaviour.

I'm not sure what to do with the space, but I'm sure we can think of something. Perhaps better bullet power selection for rambots or something like that.

Skilgannon21:28, 3 April 2013

I think I figured out a way to get those bytes back--at a loss of targeting accuracy. We'll see if it's worth it.

I highly doubt you'd be able to fit anti-ram in 3-4 bytes. But, it seems that almost every time I say that, you prove me wrong. :)

Sheldor22:19, 3 April 2013

Ooooh, that is ugly ugly ugly. But this is nano, the king of ugly, so it would only be fitting if the king was ugly too. I'm not sure what we'd gain from rambots would make up for this, but it's worth a try I guess.

Skilgannon10:58, 4 April 2013

I'm not really worried about rambots; Yatagan already does fine against them. Let's just enter this version as it is, and see if the performance loss is substantial.

Sheldor13:32, 4 April 2013

I'm not sure why, but it stayed at 249 bytes.

Skilgannon13:44, 4 April 2013