Author Topic: Zelda 3: Attempting on-more-often Lamp/Lantern  (Read 1248 times)

Xenovant

  • Tunnel Armor
  • *
  • Posts: 153
  • (ಠ_ಠ)
    • View Profile
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #15 on: February 09, 2017, 10:45:47 AM »
I would stop checking the gba port, unless you want to get a headache xD

assassin

  • Bane of Retards
  • *
  • Posts: 1,020
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #16 on: February 09, 2017, 01:24:56 PM »
well, GBA handling the spotlight in a superior way to SNES is what inspired the patch. :P

assassin

  • Bane of Retards
  • *
  • Posts: 1,020
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #17 on: February 12, 2017, 12:53:43 PM »
when assembling, 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-complex1a2.asm

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.  also, 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.

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, as well as not being able to fit the additions inline. :/

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

Xenovant

  • Tunnel Armor
  • *
  • Posts: 153
  • (ಠ_ಠ)
    • View Profile
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #18 on: February 12, 2017, 02:01:15 PM »
Cool... I'm getting close to being able to steal your code and say that *I* implemented it  :laugh:

Now seriously, I'll test it later and I'll post how it goes :P

assassin

  • Bane of Retards
  • *
  • Posts: 1,020
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #19 on: February 12, 2017, 02:18:35 PM »
that also means you'll be blamed when it malfunctions.  :tongue:

thanks.  also, what partially-lit rooms can you name off the top of your head?  i wanna visit as many as possible.

Xenovant

  • Tunnel Armor
  • *
  • Posts: 153
  • (ಠ_ಠ)
    • View Profile
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #20 on: February 12, 2017, 06:00:17 PM »
Tested. The patch works fine except for 1 thing: if you try to light a torch with the fire rod, the game crashes :P


what partially-lit rooms can you name off the top of your head?  i wanna visit as many as possible.

I have checked the ones I thought were darker, but I was wrong, all of them use the default/bright palette, so, I don't remember any, at least for now.


assassin

  • Bane of Retards
  • *
  • Posts: 1,020
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #21 on: February 12, 2017, 09:53:48 PM »
so a minor detail? ;P  oh man..  good catch.  i pasted traces of the function execution for this patch and prior one, then stared at the screen for awhile, as they were identical when possible.  finally found it:

Quote from: me
; total = 57 bytes versus 63 original

that should read "53 original".  i was absent the day they taught subtraction in 2nd grade (or counting in kindergarten?).  so the new patch overwrote 4 innocent bytes.  i'm not sure how the Lamp didn't crash it as well; Fire Rod must get the function called more times, where one of them tries to branch to the end.

back to the drawing board on fitting this inline.  the code itself seems to be fine, when it's not trampling something else.

Imzogelmo

  • Ogopogo Aficianado
  • *
  • Posts: 241
  • Gender: Male
  • Ask me about my other job.
    • View Profile
    • NEPROMR
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #22 on: February 12, 2017, 10:31:08 PM »
Have a glass of tranya, Balok. It will bring the necessary inspiration.
5/31/16 - I have an assembly of the battle portion of C2, relocated to the F0 bank, which has both vanilla and patch code in my dropbox. I'll be updating it with additional patches as I have time. I will *not* be releasing it publicly, but ask me for the link and I'll share.

assassin

  • Bane of Retards
  • *
  • Posts: 1,020
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #23 on: February 12, 2017, 11:16:40 PM »
haha.. i didn't even remember what the kid's name was.  anyway, i prefer bloodwine.  it is a good day to die!!

------------

swiped from MathOnNapkins' disassembly:

Code: [Select]
        ; branch if torch is already lit
        LDA $0540, Y : ASL A : BCS .return
       
        ; Light the torch?
        LSR A : ORA.w #$8000 : STA $0540, Y
       
        LDA $08 : BNE .notZero
       
        ; why would this ever happen give the code base we have?
        ; seems like this would permanently light the torch?
        LDA $0540, Y : STA $7EFB40, X
   
    .notZero
   
        LDA $0540, Y : AND.w #$3FFF : TAX : STX $08 : PHX

        LDY.w #$0ECA

(37 bytes)

wow, somebody at Nintendo really likes "LDA $0540, Y".  i don't (or at least not to the point of needing a "Do Not Disturb" sign every time we occupy the same room):

Code: [Select]
; branch if torch is already lit
LDA $0540, Y
BMI .return
       
; Light the torch?
ORA.w #$8000
STA $0540, Y

ldy $08
bne .notZero

STA $7EFB40, X

.notZero

; rest unchanged

AND.w #$3FFF
TAX
STX $08
PHX

LDY #$0ECA

(29 bytes)

if for some reason a caller looks at Carry (they don't seem to, as it's not like the function returns meaningful results on it), i can keep the first three instructions, then do "SEC / ROR".

am editing a bit further up than i set out to, but might as well make use of the already-commented code.

Xenovant

  • Tunnel Armor
  • *
  • Posts: 153
  • (ಠ_ಠ)
    • View Profile
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #24 on: February 13, 2017, 01:16:53 PM »
that should read "53 original".  i was absent the day they taught subtraction in 2nd grade (or counting in kindergarten?).  so the new patch overwrote 4 innocent bytes.  i'm not sure how the Lamp didn't crash it as well; Fire Rod must get the function called more times, where one of them tries to branch to the end.

back to the drawing board on fitting this inline.  the code itself seems to be fine, when it's not trampling something else.

I don't know how many times I have had this kind of mistake. You spend a lot of time checking the code and when you discover it's something like this, it makes you to want to bash your head on the table xDD


Have a glass of tranya, Balok. It will bring the necessary inspiration.

I KNEW I had seen the kid somewhere, but I didn't remember where. I thought it could be from an old chinese movie.  :happy:
« Last Edit: February 13, 2017, 01:24:13 PM by Xenovant »

assassin

  • Bane of Retards
  • *
  • Posts: 1,020
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #25 on: September 02, 2017, 06:18:59 PM »
Round 2 of staring at the computer screen for hours and wanting to put my face through it.  but this time, not due to my own retardation.

so i code the discussed space optimizations in mid-February, not touching the file since 2/16.  then yesterday, i pick it up again, and add/tweak a few labels so it'll assemble.  but it runs like a mess.  when a torch extinguishes, it's still illustrated as burning, and random un-lit torches show up in the wall or elsewhere on screen.  occasionally, they'd disappear from their original places.

this is another case of "no way my changes are causing this".  i stared at it so long that it took me from alert to fatigued, with frustration and rage varying but persisting through many levels of consciousness.  a little after waking up today, i finally pin down the issue to MathOnNapkins' disassembly (from which i've copied much of my code on this iteration; why rebuild the wheel?):

Code: [Select]
        LDA $0540, Y : ASL #2 : STA $0540, Y : STA $7EFB40, X
that should be "ASL / LSR".  while the two ASLs did seem a little odd yesterday, it took scanning an original disassembly today to learn the problem.  dunno whether it was a manual typo, or if there's some wider malfunction in any program he's using to automate things.

drove me effing nuts!  i can't really judge, as i've had incorrectly disassembled or typed instructions in my own documentation sometimes.  but these pseudo-instructions (see also: "CLC / ADC $nn" becomes "ADD $nn") annoyed me even before this issue popped up.  this is assembly language; don't obscure stuff from the reader.

anyway, this substitutes for torch-light-and-go-out-new-complex1a2.asm (which itself replaced 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

it seems to run alright.  but if you're up for further testing, that'd be appreciated.  i hesitated to ask when i knew this is not a final product candidate (as it still needs $0414 and/or room-specific checks).  but clearly, this cursed project needs to be checked at every remotely major update..  because when it's not me forgetting how to count bytes, there's trouble like this.

---

EDIT: to refresh (in case you didn't spend the last 6.5 months thinking about this patch): you want to apply a palette handler along with the above .asm file.  you preferred palette-putz2d5b.asm , available in the first post's .ZIP file.
« Last Edit: September 02, 2017, 10:42:26 PM by assassin »

Xenovant

  • Tunnel Armor
  • *
  • Posts: 153
  • (ಠ_ಠ)
    • View Profile
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #26 on: September 11, 2017, 06:24:17 PM »
Round 2 of staring at the computer screen for hours and wanting to put my face through it.  but this time, not due to my own retardation.

so i code the discussed space optimizations in mid-February, not touching the file since 2/16.  then yesterday, i pick it up again, and add/tweak a few labels so it'll assemble.  but it runs like a mess.  when a torch extinguishes, it's still illustrated as burning, and random un-lit torches show up in the wall or elsewhere on screen.  occasionally, they'd disappear from their original places.

this is another case of "no way my changes are causing this".  i stared at it so long that it took me from alert to fatigued, with frustration and rage varying but persisting through many levels of consciousness.  a little after waking up today, i finally pin down the issue to MathOnNapkins' disassembly (from which i've copied much of my code on this iteration; why rebuild the wheel?):

Code: [Select]
        LDA $0540, Y : ASL #2 : STA $0540, Y : STA $7EFB40, X
that should be "ASL / LSR".  while the two ASLs did seem a little odd yesterday, it took scanning an original disassembly today to learn the problem.  dunno whether it was a manual typo, or if there's some wider malfunction in any program he's using to automate things.

drove me effing nuts!  i can't really judge, as i've had incorrectly disassembled or typed instructions in my own documentation sometimes.  but these pseudo-instructions (see also: "CLC / ADC $nn" becomes "ADD $nn") annoyed me even before this issue popped up.  this is assembly language; don't obscure stuff from the reader.

Yeah, yeah, blame a guy who doesn't post here... :trollface:  If the game doesn't crash, you could have posted it and say it's a cool new feature, like a lot of programmers say when someone finds a bug :P

It's really funny how just 1 byte can screw a game that much xD

Quote
it seems to run alright.  but if you're up for further testing, that'd be appreciated.  i hesitated to ask when i knew this is not a final product candidate (as it still needs $0414 and/or room-specific checks).  but clearly, this cursed project needs to be checked at every remotely major update..  because when it's not me forgetting how to count bytes, there's trouble like this.

Tested and everything seems fine.

Quote
i hesitated to ask

You shouldn't. If you need something, just ask for it.

This time, I have been a little slow replying, but it's because I didn't see it earlier.  I was checking this forum like... once a week? And the last time I tried to check it, the website was offline, but I try to answer as quickly as possible. Normally, if I see activity, I check it every day.

assassin

  • Bane of Retards
  • *
  • Posts: 1,020
  • space bears are not gentle!
    • View Profile
    • My Barren Webpage
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #27 on: September 12, 2017, 06:44:56 PM »
- maybe if i sandwich his username in between enough profanity, it'll act as a summon, and he'll finally make his first post in 9.5 years.
- thanks.
- yeah, the board was offline for nearly a week.  9 days is a fairly timely reply regardless, so no complaints here.

-----------

Quote from: me
dunno whether it was a manual typo, or if there's some wider malfunction in any program he's using to automate things.

investigating this some, here are match counts for text searches in his entire disassembly:

"ASL A : LSR" = 1
"LSR A : ASL" = 1

"LSR #3 : ASL" = 1
"LSR #4 : ASL" = 1

(no other matches for "ASL/LSR #N : LSR/ASL" (with N 1 thru 5) were found.)

that seems a bit low, but it could just be Nintendo's coding style.  and i can't say anything concrete without knowing the actual number of these pairs used in the game.  which i unfortunately have no idea how to search for 2 bytes at a time without a billion false positives.

so hopefully MoN will see this topic, and shed some light on whether he used any automation to generate these pseudo-instructions.

MathOnNapkins

  • Pandora's Masking Tape
  • *
  • Posts: 1
    • View Profile
Re: Zelda 3: Attempting on-more-often Lamp/Lantern
« Reply #28 on: September 14, 2017, 12:46:29 AM »
A considerable percentage of the assembly was done by hand (idk, 25%? ). When I started to realize just how much code there was I wrote a utility called SnesDisasm that automated it to a large degree within the context of one subroutine. You write in a lower and upper bound for what you think is a subroutine (or subroutine with multiple entry points) with some initial guesses as to MX flag state and it tries to analyze whether it's a closure of sorts. Still fairly tedious but a few order of magnitudes faster and far more accurate. Sadly I still locate errors that were obviously the result of transcribing what I saw from a hex editor at 7 hours past bed time. If there's an error in that utility I suppose I could pull out the code, compile it, and see if the error is reproduced. However, the ASL, LSR, ROL, ROR, etc #{quantity} syntax is an xkas-ism. Thus, if there were errors on lines like that they were likely a hand edit done later anyway in the name of horizontal code golf.

A goal I had for a long time and still have is an assembler that takes my disassembly as input and validates that it produces the same binary as the vanilla rom. Just haven't gotten around to that for a variety of reasons. It would accept things like ADD, SUB, which are pseudo-instructions. I don't feel that this obscures the semantics at all, as long as there's no branch target between the CLC and the ADC, for example. pseudo instructions are quite common in assemblers in the broader industry. I have a heavily modified version of xkas that is WIP that was supposed to do this, btw.

Btw I'm on the Discord below regularly in #alttp-hacking if you need live Chat Support with a Friendly Representative:
https://discord.gg/FF4T4A

« Last Edit: September 14, 2017, 02:16:53 PM by MathOnNapkins »