Banner
Views: 808,229,255
Time:
23 users online:  1UPdudes, AnasMario130, Atomicatoms,  BeeKaaaay, Blizzard Buffalo, BuuNinja, CalHal, Dark Prince, HLXY, Infinity, JamesD28,  KevinM,  Lazy, mariosr, Mr. MS, Qrtr The Dunce, Sariel, SimFan96, StayAtHomeStegosaurus,  Tahixham, Vhack, VLSkoot, wuffalo - Guests: 124 - Bots: 205 Users: 42,442 (2,001 active)
Latest: 00_marvelouschester_00
Tip: Bad things to do in the title demo: Enter a door or a pipe, activate a P-switch or a star, complete the level, hit a message block, or die. These will either glitch the music, or force the player into an endlessly looping title level until they reset the game.Not logged in.
ON/OFF Ambiance by Blind Devil
Forum Index - Valley of Bowser - Moderation Questions - UberASM - ON/OFF Ambiance by Blind Devil
Pages: « 1 »
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.
Pages: « 1 »
Forum Index - Valley of Bowser - Moderation Questions - UberASM - ON/OFF Ambiance by Blind Devil

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 7

Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy