Odd code...

I found some interesting stuff in the code. Functions that do absolutely nothing. Here's an example.

00409670 push ebp
00409671 mov ebp, esp
00409673 pop ebp
00409674 ret

Basically this saves the base pointer, grabs the stack pointer, and immediately plops the base pointer back into whatever it was before returning. And it's never called anywhere, to boot.

There are a few cases like this. And a lot of unecessary interrupts before most functions (padding, basically.) Very interesting stuff for anyone intending to write their own code - extra space. Even a handfull of bytes can be important when dealing with machine code.

I'm going to take a wild guess here - Pixel's compiler wasn't configured to optimize its code too well. Any compiler worth its salt should've been able to detect unused functions and remove them. But hey, free space is a good thing for use hackers so who am I to complain?

Other examples include various wrappers around some functions. More code that should've been optimized out when compiled. If not simply avoided when writing the game's code.

 

What did he write Cave Story in, anyway?

 

Seems to be Microsoft Visual C++. It's DEFINATELY written as an object-oriented program, as object memory footprints are very easy to spot in assembly.

 

I think too its C because in the Exe where some thinks like: C++ Runtime package Required

 

I belive that Pixel has mentioned on his site that he writes his programs in C++.

 

It seems a few of these "blank" bits of code are used in pointer tables (ie, boss entity 0x00 jumps to a blank function.) Despite that, a few bytes could be saved by simply not dealing with the push/mov/pop at all and just returning straight away.

I've found that the best way to get blank space is to mooch off of entities or bosses not being used in your hack. To be safe, you can alter their pointers to point to entity/boss 0x00 (meaning that if it gets used either explicitely or implicitely by another entity it'll simply do nothing instead of crashing hard) and then you have a few hundred bytes of blank space you can have your functions jump to.

Useful? You betcha! Suppose you were to one of the major NPCs (say, Itoh) you'd have access to plenty of space without having to sacrifice anything important in return. Unless you're using the original scenario data, in which case you'd have to either rewrite some of these functions to be shorter (easy - entities often pick at [ebp - 08] unecessarily) or try to find free space elsewhere by sacrificing parts of the game mechanics...

I'm totally creating super-heated rooms that require the use of a heat-suit to cross safely. I can now branch in my progressive drowning script and add additional checks.

I also plan on removing the need for the (C)Pixel image protection. Free space may be necessary, and I might ditch a lesser-used sprite (maybe Pixel the Cat) to fit the new code in. I'll post the code if it works out fine.

 

I think I may've found a bug while poring through the code. This is largely for the sake of curio, and nothing serious.

When using AM- to lose a weapon, the game will iterate through the 8 weapon "slots" and check if it finds the weapon ID in one of the slots. If the slot "counter" used to determine which slot the weapon is in hits 8, it means the game checked every slot and the weapon wasn't found.

The problem lies in the part where the game decides wether to have the function fail and exit, or to delete the weapon. Here, instead of checking if it's on slot 8, it checks if it's on slot 32 (the max amount of items, two functions down in the code.) This means the function will never fail and will always proceed to the part which shifts the next weapons back by 1 slot to fill in the hole left by the removed weapon.

The game will not crash because another check is made to see if the loop to go through each weapon to move back by 1 slot has ended. This one is at the start of the next bit of code, and DOES check against 8 instead of 32. If the check fails (ie, we're on slot 8) the function says it worked and exits without changing anything.

The only issue this causes is that the code acts like a weapon was removed when, in fact, the function failed. It doesn't seem to have any practical impact on the game but the code DOES execute a different part if a function failed, which isn't the case here because of the bug.

Something to consider when removing weapons with AM-. Make sure you don't attempt to remove non-existant weapons or unpredictable behavior could occure. On the other hand, the game might end up just fine. Do this at your own risk.