An odd checksum - others like it?

[nibble4bits]

From HPI-fmt2.txt version 1.0 (HPI is a format for Total Annihilation):

CHECKSUM CALCULATION

The checksum in each HPIENTRY2 is calculated from the uncompressed file
data.

It's actually four checksums in one, each 8-bit byte being one of the
checksums.

The first one is the sum of all the unsigned bytes in the file.

The second one is the cumulative XOR of all the unsigned bytes
in the file.

The third one is the sum of all the unsigned bytes in the file, each
byte XOR'd with its offset before being added.

The fourth one is the cumulative XOR of all the unsigned bytes 
in the file, each byte XOR'd with its offset before being XOR'd.

Notice something 'funny' about the last one?

Hint: A 256-byte table would be my first optimization. Can you do better without a table?

Anyone have some good puzzles related to this? Like why they did that in the first place? Other odd algorythms that do something like that? I'm thinking we could come up with challenges where someone posts an example and we try to remake it using our imaginations.

[maxal]

Originally Posted by nibble4bits

The second one is the cumulative XOR of all the unsigned bytes in the file.

[...]

The fourth one is the cumulative XOR of all the unsigned bytes
in the file, each byte XOR'd with its offset before being XOR'd.

Notice something 'funny' about the last one?

Not funny but stupid. The forth byte is always equal to the second byte XOR some constant depending only on the length of the file, not its content.