Attempting on-more-often Lamp/Lantern

the SNES game gets rid of the lamp/lantern spotlight as soon as you light one torch.  that means the area around Link actually gets somewhat _darker_ when the rest of the room gets lighter.  this is dumb.  why should the Lamp/Lantern lose its perpetual burning ability just because you lit a torch?  the game's already docking you MP for said lighting, and it's possible you lit it with Fire Rod anyway.

the GBA version remedies this silliness by keeping the spotlight until slightly after you've lit 3 torches, and restoring it whenever the third goes out.

here is my pending attempt to do the same thing on SNES:

http://assassin17.brinkster.net/forum-posts/zelda-torches/torch-alpha1.zip

see contents-readme.txt for explanation of the files included.

applying both light-torch-new1.asm and torch-go-out-new1.asm will keep the original spotlight until you've lit 3 torches, and restore it whenever the third goes out.  however, it has an issue of a darkened ring around Link once two torches are lit, because it doesn't alter the perimeter of the spotlight as the room gets brighter.

the game achieves ambient room darkening/brightening and the lamp/lantern spotlight with color translucency math, specifically subtraction of a value ranging from 0 to 31.  if you turn off Transparency effects in Snes9x, you can see the black and dark gray spotlight on BG #1.  black has color components of zero value, so when it's subtracted from the room background, you keep full brightness, while subtracting gray makes it a little dimmer.  everything outside this spotlight overlay is subject to the room-wide color reducer, which is determined by different target values based on # of torches lit: 0 torches = 31, 1 = 8, 2 = 4, 3+ = 0 .  the reducer isn't immediately set to these values, but gradually adjusted to meet them.

finding the black and gray overlay in ROM and drawing a larger alternate would make a nice feature for a Super Lamp, btw.

i considered dealing with the darkened ring around Link by having alternate-colored overlays depending on the lit torch count, but this'd take a bit of extra ROM space.  also, it wouldn't match the GBA's nice behavior of having the outer edge of the spotlight change gradually in response to torch lighting/extinguishing, much as the rest of the room already does.

dynamically redrawing the gray pixels would be too slow and involved, so i went at it a third way: the outer spotlight's palette.  it's Palette 11h, and has default color component values of 6.  i modify it from an interrupt routine based on the ambient color reducer.  hopefully, entry 11h is always used for the spotlight, it has 6s everywhere it's used, and it's not used for anything else; otherwise, there'll be omissions and side effects.  the fact that 11h is outside the range of entries in the 7E/C500 palette table that get darkened then gradually lightened when you enter a room gives me some confidence that it's a special case and there won't be conflicts.

also, having my new code run 60 times a second in a speed-sensitive routine might cause issues, though it seems alright in Snes9x.  calling it this often does allow me to gradually alter the outer ring.

there are three versions of the palette adjuster included.

i welcome feedback on all files, and discussion of the optimal color adjustment.  it'd be damned cool to have a "master formula" based on the color reducer's distance from 31, as well as its distance from the default value of the region being altered.  but that might be too elusive to pin down, or too involved to code.  so individually deciding the result of all 32 input values is also an option.

even with the patch, the SNES version still gets rid of the overlay as soon as the 3rd torch is lit, so there'll be a few frames where the area around Link is darker than it was just before.  in contrast, the GBA gradually phases out the spotlight.  (i'm impressed by what they did on that version, even if the outer portion of the spotlight has that silly checkering.)  ways to match this might be keeping the overlay on all the time (a bit CPU-intensive), or creating a custom "overlay removal pending" variable (harder to code).

finally, help in making sense of Function 0D/FA33 and Variable $0458 would be appreciated.

I think what is interesting is that the Lantern has a hidden ability which does not make it obsolete unlike the Fire Rod.

since applying multiple .asm files can be a chore, added .IPS patches and anti-patches to .ZIP file.

----

EDIT: an off-by-one mistake on a free space address means you could never make it past the title screen!  that's what i get for testing only with savestates.  updated .ZIP file with working patches.

work's been done since then...

this replaces light-torch-new1.asm and torch-go-out-new1.asm:

http://assassin17.brinkster.net/forum-posts/zelda-torches/torch-light-and-go-out-new-complex2a1.asm

main changes:

1) it tests Var $0458 to exclude the Uncle/Lamp room (and probably the Ganon fight, Aginah room, and old man mountain cave) from the spotlight.

reason being is that i visited the Lamp/Uncle room on GBA (Euro version, as that's what has the uber savestate), and there's no spotlight, both before and after lighting/expiring the torch.  as mentioned, this version of the game is pretty robust on how it handles the spotlight (i.e. changes it gradually, even after lighting the third torch), so i don't feel the need to exceed their high bar.

as for Aginah's room and the old man's cave, GBA has the torch count at 2, but ignores it and strangely has the rooms at full brightness.  while i'm not going for the latter, Capcom's imprecision in these rooms means i don't feel the need to work out a spotlight here.

the Ganon fight is a bit weird (on SNES, anyway).  it has 3 torches lit to start, with one being an offscreen torch that always stays on.  once you light the two torches, then when they each go out, having one (visible one) on is no brighter than having two.  and the game constantly overwrites the overlay variable with 0 in most cases (1 is what allows for the spotlight).  so i'll respect that and not try to force a spotlight there.

2) it adds a check for the Lamp to the torch lighting and extinguishing routines, to close a loophole hacks could have if you get the Fire Rod before the Lamp.  if $0458 isn't == 1 (and you have the Lantern), this falls back to the game's original lit torch cutoff of 0/1 as opposed to just disabling the spotlight.  i do this to defer to the fact that the original game has no $0458 checks in these two routines, and still works fine.

------

the current revision edits a lot more because it optimizes surrounding code to make additions fit.  thanks to MoN's disassembly for laying out and describing things.

------

TODOs:

i should probably add a check to skip the spotlight if $0414 is 2, even though i don't yet know of any places where that'll be the case with $0458 equaling 1.  what's holding me back is not understanding how $0414 works. :/

finally, my interrupt palette code should probably check for Var $1D == 1 instead of just > 0, which'll be an easy change.