| Name: | Fleeing Keyhole Sprite V1.0 |
| Author: | TheXander |
| Added: | |
| Tool: | PIXI |
| Type: | Standard |
| Dynamic: | No |
| Disassembly: | No |
| Includes GFX: | No |
| Description: | Fleeing Keyhole V1.0: Description: This is are a variant of the Vanilla Original SMW Sprite 0E: Keyhole, but, when the player are close to this in certain range, he'll start fleeing away of the player! This come with various options that let you make more interesting the behaviours of this custom keyhole sprite! Features: PIXI Support/Compatibility. SA-1 Support/Compatibility. JSON Support. A documentation (Readme) file. Use Extra Bit & 2 Extra Bytes with features! Allow customize the sprite easily with a bunch of defines! More details are on the documentation (Readme) file! Requested by Green |
| Tags: | enemy fly key keyhole lorom message movement pacifist sa-1 secret exit |
| Comments: | 3 (jump to comments) |
| Rating: |
Download
13.93 KiB | 55 downloads
Comments (3)
- Lunar Magic v3.40
- SA-1 Pack v1.40
- PIXI v1.40
- BSNES v115
Removed attack, added enemy and pacifist tags.Like the fleeing moon and goal sphere, this spices up some things, especially so because the secret exit is usually the harder exit to get.
Just don't use the kill option, that feels like a dick move.
As for code improvements, I immediately notice that the keyhole activation behaviour is bitwise. This is unnecessary as each behaviour is mutually exclusive and an index-based approach is much easier for user-friendliness (exponential numbers are weird), for coder-friendliness (since you can simply use a pointer table) and allows you to use up to 256 different actions (which for that matter, should have included hurt and kill at the same time).
I also would have moved the attack setting into the second extra byte since doing so frees up the extra bit for custom purposes (that being using it as another bit for the sprite number like Tessera and GIEPY allows you).
The included proximity routines also are unnecessary since you can use the included
SubHorzPosandSubVertPos, respectively, which may output a ranged value but you can always invert them yourself.Another improvement (though it is a gotcha moment) is to store the index of the carried key somewhere because you're checking for a key twice. Doing so reduced the amount of checks through all sprite slots which is worth, particularly with many keyholes onscreen as the second image shows.
On a more minor note, you didn't add
|!bankfor long subroutines. This is because if a ROM has fastROM enabled, the routine won't take of the speed advantage (again, this can be negligible if it's only one keyhole but the aforementioned image has a legit usecase for multiple keys).I also have found two functional bugs: The code which checks for a carried key only checks for the key in the highest slot (this is a vanilla bug but a bug you should fix nonetheless) and the other is that a key which only flees at a key in proximity doesn't check for one carried in Yoshi's mouth (though this an easily exploitable feature — make it an optional setting next time!).