1.2.0

Jump to navigation Jump to search

It may be compiler dependent, I am just using standard jdk 1.6, but every time I have sized that it has been 2 bytes different.
1 is dconst_1, size 1 byte.
Any other double constant (except zero and possibly stuff that can be cast from an int constant) is
ldc2_w, indexbyte1, indexbyte2, size 3 bytes.

As to which is functionally superior I am not sure, I haven't done extensive benchmarking on that variant of Yatagan movement as those extra 2 bytes were not enough for me to add anything else, so I didn't use/test it much.

Nz.jdc (talk)02:00, 13 June 2013

In Jikes that also saves 2 bytes. I think this would be a interesting one to try out after 1.2.1 stabilises.

Skilgannon (talk)05:08, 13 June 2013

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Yatagan/Source/1.2.0/reply (15).

So I was testing some other stuff and decided while I was at it to bung some yatagan variants through my benchmarks.
Note, take the figures with a grain of salt as there can be up to 1% jitter and these are all quite close. Also my figures often show .5 to 1% higher than the rumble, but what I got was:

  • jk.sheldor.nano.Yatagan 1.1.7 79.6%
  • jk.sheldor.nano.Yatagan 1.2.1 78.8%
  • nz.jdc.nano.Yatagan117a 1.0.0 79.4%
  • nz.jdc.nano.Yatagan117b 1.0.0 79.0%

1.1.7 and 1.2.1 are your released versions, both scores align reasonably with the rumble and show 1.2.1 being down a little.
117a is a copy of 1.1.7 with the movement code change suggested above.
117b is a copy of 117a, but with the addition of setAdjustGunForRobotTurn(true);

Not sure what is causing the (relative) weakness in 1.2.1, it could be the change in energy detection, or it could be putting oscillate first in the table, or another table bug. Another possibility is the gun adjust. I have varying results with that and often find it hurts rather than helps the score. The result of the otherwise identical 117b being worse than 117a leads me to believe the gun adjust is a factor.

Nz.jdc (talk)10:30, 13 June 2013

It looks like putting the oscillate first was the issue, 1.2.2 is tied with 1.1.7. I wonder if the setAdjustGunForRobotTurn(true); would be better replaced by setAdjustRadarForGunTurn(true); to cut down on the radar lock issues?

Skilgannon (talk)13:49, 13 June 2013

Version 1.2.2 isn't tied with 1.17, it's an all-around improvement. See a comparison here.

Infinity radar is fundamentally inaccurate. An adjustment wouldn't be worth the codesize.

Sheldor (talk)16:54, 13 June 2013

Yeah, but even infinity lock will slip ~5x less if we change to setAdjustRadarForGunTurn instead. Seriously, it slips a lot, watch it in some battles.

Skilgannon (talk)18:44, 13 June 2013

I suppose we could try it.

Sheldor (talk)19:03, 13 June 2013
 
 

That seems to have made quite a large difference. I suppose I should not be surprised about a pattern matcher not liking gaps in its pattern. @#$!&* pattern guns, they are rather strong. I'm not sure even my cheaty dev version will have much margin over 1.2.3. I had better get back to the tuning. Or start praying for inspiration from saint Michael.

Nz.jdc (talk)02:50, 14 June 2013