|File Name: ||ON/OFF Ambiance |
|Submitted: ||13 September 2017 - 19:45:02 PM by Blind Devil |
|Authors: ||Blind Devil |
|Type: || |
|Includes GFX: ||No |
|Includes Hijack: ||No |
|Featured: ||No |
|Description: ||Placing this in a level will make it change its music, brightness and/or turn certain sprites into different ones depending on the ON/OFF switch status. |
I was rather unsure whether this should be approved but in the end, I decided it has too many caveats to be fully usable. It works and the effect is amazing, but let's see why rejecting this seemed like the better option.
Starting off, the SA-1 check on line 72 might break in later versions of Asar (I've seen cases in the past where implicit != 0 was being incorrectly assembled by them). Not to mention that with the currently waiting update of UberASMTool
, manually creating these defines becomes unnecessary.
Speaking of checks, having the user manually set the presence of AddmusicK is not very nice, especially considering how buried the define is. You can automatically determine the values of both !AMKFlag and !AMKRAM using if statements and Asar's reading functions. read3($048E44) == $EAEAEA
should be enough to test if AddmusicK is present (random hijack from tweaks.asm). !AMKRAM is harder to find dynamically (and, considering nobody changes it, it's rather unnecessary to do it).
The biggest problem with this is the sprite changing feature. The bigger issue is that it relies on PIXI without ever mentioning it. The reason is that you check the extra bits of the sprite (line 193) without considering that the sprite table for them is uninitialized memory in a ROM without PIXI used on it. This causes unpredictable behavior. You should detect PIXI (read4($02FFE2) == "STSD"
might do it) and only check for its custom tables if it has been used.
Switching sprites also isn't perfect - you don't account for the extra bits of normal sprites (which isn't a problem without PIXI and also only affects the goal tape) and you don't restore the extra bytes of custom sprites. Adding the ability to have different extra bits (and possibly extra bytes) for the two states would be a welcome feature, too.
The loop to switch sprites is very inefficiently coded. For each sprite slot, you loop through each table entry and only then do you check if the sprite can at all be changed. Moving lines 181-191 out of the table loop should speed this up. With some creativity, there might be ways to make it even more efficient.
Try to improve this before resubmitting it. At the very least, fix the dependency on PIXI since it doesn't need to be there.