This patch will make so that a lot of sprites that use the starting X/Y position to set some property, will use the extra bit instead. Check out the included readme for the complete list and info on what the patch does. You can also turn this off for specific sprites by changing the defines in the asm file.
Note that you need to run a sprite tool (e.g. pixi) on your rom at least once in order for this patch to work properly.
Removed one line of debug code. Nothing else has been changed.
A well-put-together patch that affords one more control over their sprites, always a plus.
Do note that Lunar Magic does not change its display to match the revised sprite behaviors, which takes some getting used to. The only sprites that really become problematic in this regard are the line-guided enemy sprites (Chainsaws, Grinder, Fuzzy), which have hardcoded spawn position offsets (which is why they jump back and forth when dragged around in Lunar Magic). To place these sprites properly with the extra bit clear (i.e. set to move down/right), first place the sprite at the desired location. Next, check the Lunar Magic tooltip - if it says the sprite is set to move down/right, then nothing else need be done, it'll spawn where you put it. If it says it's is set to move up/left, keep sliding the sprite to the right - it will continue to jump back and forth before ending up one space away from the desired location, but with the tooltip reading down/right. Finally, move the sprite left or right one space to place it in the correct location. It's graphic in Lunar Magic will shoot 22 tiles over to the right, but the sprite itself will spawn where it's supposed to.
Tested with Asar 1.71, Lunar Magic 3.11, SA-1 1.32, Snes9x 1.59.2, PIXI 1.2.14.
That's really cool...could another future update possibly allow doing something similar with the extended objects that use the X/Y position to set a property if the extension field was used to define what those extended objects would contain without the need for using custom blocks (for example, making one instance of extended object 35 contain a shell regardless of the X position, then having another copy of the same extended object contain a key that was in the same column as the other one)? I'm really curious.