Thread history
| Time | User | Activity | Comment |
|---|---|---|---|
| No results | |||
I ran some tests, and it looks like we'd only get a score in the sixties. I'm not worried though, because I don't know of a single bot in the rumble that would fire bullets less than power 1.0 at close range, except in the endgame. And even if there was one, it would likely have a HOT gun, which would be dodged by orbit movement anyway.
Well, let's see how it does! =)
Hmm, apparently not quite as good as 119. The scores may not have quite stabilised yet, but it has dropped down to second with 78.06 APS, about -1.2 IIRC :(
On the plus side I briefly get to retake the lead :)
Not to worry though, I have the superlatively evil (nasty, unpleasant, dishonourable, cheating or the insult of your choice) version 1.2 of PralDeGuerre under development. Now if only it performs up to the statistical predictions...
By the way, how much space is that move change saving? I think Sheldor said 2 bytes.
An alternative that might perform better (can't say for sure, you would have to benchmark it) would be to use the old move, but change the "... - (1.1 - 1e-8) ) <= 1)" to
"... - 1) <= 2)".
This is slightly less accurate as the energy detect is .001..3.999 rather than .001..3.001, but it could work better.
You would also need to update the rand chance to be "4 / 0.6*Math.sqrt(..." rather than "3.0/(0.6*Math.sqrt(.." to account for the wider window.
The drop in score is due to two problems with the table. I just fixed both of them.
Yep, this method of enemy fire detection is two bytes smaller than the previous. The other char based check you just posted would be (going by memory here) only one byte smaller than the original, which would be one byte bigger than my new method.
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.
