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.
In Jikes that also saves 2 bytes. I think this would be a interesting one to try out after 1.2.1 stabilises.
Ah well, I had a few hours at the top, but it was not to last.
It has only had 1000 battles, but this version looks to have lost half a point from 1.1.9.
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.Nz.jdc (talk)
Return to Thread:Talk:Yatagan/Source/1.2.0/reply (16).
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?
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.