1.2.0
This thread or its parent was deleted.
This looks really cool! The only problem I can see is if the bullet power is below 1, it won't react to fire in the oscillate mode. I also fixed a tiny problem in the number of values in the REVERSE_ON_ENEMY_FIRE block.
Interesting. Is this functionally different or just for the codesize?
If so how much is it saving?
I remember trying something similar to remove a conditional and replace it with a formula and it came out larger so I ditched the idea. Admittedly I was doing something a little different, but cool if you have gotten it to work for you and gained codesize.
I noticed the problem with casting the energy drop to an int, but I figured that if an enemy was firing power 1s at a distance of around two hundred pixels, we would be able to get a score of 80+%, even with RM.
@Nz.jdc
This method saves two bytes over the conditional method (just enough to fit setAdjustGunForRobotTurn(true)). I don't think it is functionally different from a conditional check. If it is, I probably did something wrong.
Off Topic: I don't understand how your new Adept movement works. What's the point of moveMode ^= 1? Wouldn't that just return moveMode unchanged?
The old neophyte movement changed moveMode from 1 to -1 and back on every bullet hit. Then used direction *= moveMode to flip between orbit mode and oscillate mode whenever we get hit.
The new adept movement keeps that, but combines it with a yatagan style onDeath lookup table. However note that in adept onDeath uses moveMode += 2. ^ is the XOR operator, so on every bullet hit we toggle the low bit. This allows it to combine pure orbit, switch on death to pure oscillate. Do that a few times as yatagan does, then after several deaths it will go back to toggling between orbit and oscillate on every hit.
D'oh! I thought that carets were exponentiation operators. Your movement makes much more sense to me now that I realize they are inequality checks.
Sorry for being all pedantic about it, but I just wanted to make sure you understood that XOR isn't an inequality check.
if you have two numbers say:
a=1000101;
b=1011110;
then c=a^b; sets each bit of c to 1 iff that bit in a is one or that bit in b is 1 but not both. Otherwise the bit is set to 0. So c==0011011 is true.
Again. Sorry for being pedantic but I wanted to make sure that this was clear.
