Disable bomb damage in PW?

Ok, so I took a shot at the speed hack.  The original code looked like this:

Code:

seek($07FA80)
    lsr 
    lsr
    lsr
    pha        
    phb        
    phk        
    plb        
    lda $1a    
    and $fb00,y
    bne +
    plb
    pla
    lsr
    bra ++
+;  plb        
    pla
+;  rtl        


New code:

Code:

seek($07FA7F)
    lsr
    lsr
    lsr
    pha
    phb
    phk
    plb
    lda $FB00,y
    beq +
    and $1A
    beq ++
+;  plb
    pla
    lsr
    rtl
+;  plb
    pla
    rtl

The new code was 1 byte longer than the old code, and there was a subroutine directly after it, so I did have to move the code and adjust the jsr at $05FA14 accordingly.

This basically allows for values other than $01 in the table at 03/FB00-FF to result in different speeds (well, technically it already did that, but it only made things faster instead of slower, I'm looking for speeds between 100% and 200%).  $00 and $01 behave the same as before, but you can use other values too.  It's kind of hard to explain, but to keep it simple, you might as well just stick to $00, $01, and $03.  It's not the values that determine the divider, but the number of 1-bits, and also to avoid weird stuttering you should fill the bits from right to left (unless you want to create a sprint-walk-sprint speed, then try left-shifting the bits).

Speed values
$00: 100%
$01: 200%
$03: 150%
$07: 125%
$0F: 112.5%
$1F: 106.25%
$3F: 103.125%
$7F: 101.5625%
$FF: 100.78125%

thats correct - when you actually think increasing the value will make things quicker but it actually makes the sprite move slower!

At one stage i was going to increase the speed of other sprites but i never got around tinkering for the correct value.

the hooking routine calculates the amount of pixels to move - i haven't checked if it applies to only soldiers or everything movable. If one less lsr occurs during the timer flag, the sprite moves quicker as the resultant value is larger (move more pixels). In other words, if you want to do 400% speed (i believe soldiers jumps over bushes in that setting) you'll need to remove one more lsr.

Euclid wrote:i haven't checked if it applies to only soldiers or everything movable.

It does apply to all sprites.  When I was messing around with things, I accidentally swapped a branch condition, and it ended up speeding up everything *except* the soldiers, and in the opening sequence, your uncle ends up moving too fast, overshoots the door, and walks through the wall instead

So yeah, the sprite table is at 03/FB00-FF (see lda $FB00,y where y is the sprite index), and it handles all of the sprites, by index (e.g. the soldiers are sprites $41-$49, which is why the values go at 03/FB41-49).

Euclid wrote:If one less lsr occurs during the timer flag, the sprite moves quicker as the resultant value is larger (move more pixels).

Yep.  And, it looks like my original numbers might have been off.  It seems like what the original code does is essentially "every other counter tick, double the movement distance" (because it only skips the final lsr if the value in the lookup table ANDed with the counter value is not 0, i.e. if the table says zero it always performs the final lsr, and if it's 1, then it skips the lsr whenever the counter's LSB is 1).  So, I guess it was actually 150%, not 200% (100% every even count, 200% every odd count).

Originally, you could have used other values like $03 to make them even *faster*.  Take $03 for instance.  It would take the counter, and it with $03, and if the result was 0, then it would move at the normal speed for that count, but then for the next 3 counts it would run double speed.  So, in essence you could select values between 150% and 200% (plus the original 100%).  I modified the code so you can select values between 150% down to 100%.  You're right that you could remove another lsr, and increase even more.  I might give that a try, I have a few extra bytes of code space to work with.

The reason you want to "fill the bits from right to left" is because of the way a binary counter works.  Any single bit in a binary counter, when graphed as a square wave, will have a 50% duty cycle (50% of the time it's a '1', 50% of the time it's a '0'), but the higher you go, the LONGER it stays as one or the other.  And because, in this case, the behavior is "go twice as fast when it's a 0, otherwise go normal speed" the behavior would look like this for different values:

$01: FSFSFSFSFSFSFSFS
$02: FFSSFFSSFFSSFFSS
$04: FFFFSSSSFFFFSSSS
$08: FFFFFFFFSSSSSSSS

Eventually, the fast and slow times would get large enough that it would make the speed appear to "stutter" where the value of $01 switches back and forth so fast you don't realize it's actually alternating between 2 different speeds.  Maybe this is actually something you would want to happen for certain sprites, who knows.  Might be worth playing around with.  For now, $03 (125%) seems to be a good value, but if I increase the max speed by relocating another lsr, I'll let you know.  It might actually be worthwhile, because like I mentioned, anything other than $01 or $03 doesn't really make a noticeable difference.

Hmm... weird, it seems that it might not actually affect all sprites, some sprites enter that subroutine with Y set to 0 (so don't try and use this for the raven sprite, I guess).

However, just for kicks, I did try doubling the "fast" speed, with some interesting results.  This also pretty clearly shows the "stuttering" I was talking about, so I'll need to refine it a bit if I want to try enabling the faster speed like this.  Also interesting is the way that the enemies slowly get pushed off the screen because of this.  I guess their "return to the original position after the recoil" routine hits the counter at a different time and doesn't move them fast enough.

I... uh... I think I broke it...