Language…
14 users online: caioskii, Cristian Cardoso, fanfan21, Golden Yoshi, Green Jerry, Hayashi Neru, JezJitzu, Josuke Yoshikage, KoJi, Maw,  Nanako, Shomi, tOaO, yoshi9429 - Guests: 248 - Bots: 286
Users: 64,795 (2,377 active)
Latest user: mathew

Invisibility Effect by westslasher2

File Name: Invisibility Effect
Submitted: by westslasher2
Authors: westslasher2
Type: Level
Includes GFX: No
Includes Hijack: No
Featured: No
Description: This code allows Mario to become invisible when the level starts, this includes many customizable options like showing or hiding Mario if the on/off switch is triggered, if he is on ground or not. etc.

Includes a block that hides Mario as well.
Screenshots:
This is definitely an interesting idea for an effect but the code quality and documentation are severely lacking, which is what ultimately made me reject it.

The code consists of a lot of copy-pasted conditionals, all of which conflict with each other. Granted, you did warn about that, but the names of the defines are quite misleading. The code actually hides Mario if the condition is false, it doesn't show him if it's true. Usually, this is an insignificant distinction, but in this case, it actually does matter. For instance, one would expect that setting both !normal and !ShowMarioOnBlueSwitch to 1 would hide Mario for the entire level but show him when a blue P-Switch is active; this isn't actually what happens because the code only hides Mario never shows him (as the effect's description would suggest), so setting !normal to 1 dwarfs all other settings. It would be much better if the defines controlled not whether the check is active, but rather whether it should show Mario, hide Mario, or do nothing. The current way you handle it greatly hinders the usefulness of the effect.

The same usefulness problem applies to the block - it's nothing more than a generic block which hides Mario. It can't override the UberASM code's effect, only complement it. One would expect to also be able to show Mario with the block, thus overriding the main code's effect.

Apart from the misleading defines, the code's quality is not the best, either. Almost all conditions unnecessarily compare to 00. Another offender is the !ShowWhileCarrying check, which can easily just use a bitwise AND operation to check both $1470 and $148F. It also bothers me just how much code is repeated - this also contributes to the usefulness problem I mentioned above. It would be a better idea to keep a planned value for $78 in another register or scratch address, then actually store it before returning. This would also make it easier to implement my suggestion for allowing each check to show or hide Mario.

Overall, this is a nice idea, but it's quite poorly executed. The effect's code is rather inefficient, which leads to usability problems for the end user, especially considering the poorly named defines. With a bit more effort, this could be turned into something very useful and customizable. Right now, however, it's just a bunch of simple code which conflicts with itself.