Parallel Worlds 1.3 Progress Thread

[qwertymodo]

Since school is wrapping up this week, I'm finally at the point where I can take another crack at Parallel Worlds and put out a nice, polished 1.3 version.  I'll be incorporating many (though not all) of Puzzledude's v1.23 fixes, as well as any others that I am able to address.  Also, to avoid another buggy release, I will need beta testers.  I will not release publicly until I have had at least 2 full playthroughs of the main quest from people other than myself.  Please comment here if you know of any existing bugs that are not listed here, or if you want to help test.

Known issues:

• Wallmasters in Din's Catacombs cause the lantern cone of light to disappear
  

Typos:

• Guardhouse HUD "Celler"
  

Possible issues:

• Jumping onto ice bug
  
• Day/night palette too dark
  
• King Helmasaur damage class
  
• Boss respawn tags (Darunia's Cavern Lanmolas, Tower Moldorm)
  
• Ending sequence incorrect sprite palettes (torches/chests)
  

Possible changes/improvements:

• Allow returning to the Church Passage to get the boomerang if you missed it
  

Re-balancing:

• Adding fire damage to the lantern might be OP against early bosses (esp Lanmolas)
  

Fixed:

• Overworld ice tile detection (disable turning with boots on ice)
  
• Icy world jumping skull sprite graphics
  
• Icy lake overlay issue (keep the master sword ASM, just fix the overlay)
  
• Darunia's Cavern doors (use PD's fix)
  
• Infinite dig tile (use PD's fix)
  
• Properly address any bugged entrance Y coordinates
  
• Add Cane of Byrna in Darunia's Cavern, heart container alt
  
• Vitreous gfx issues
  
• Incorrectly facing eye laser in Ruto's Fortress
  
• Sky Isles Tile issues due to the church fix
  
• Shadow gfx issues
  
• (2nd quest) Fairy pond allows you to throw a non-existent Hylian Shield, which breaks the secret dungeon
  
• Ending credits typo "SLIENT TOWER OF THE SKIES"
  

Also, I need to go through the v1.23 "remaining issues" list to see which ones I feel I can tackle.

Edit: See also https://www.zeldix.net/t1270p75-parallel-worlds-v1-2-public-release#18850

[Erockbrox]

I haven't played the newer versions of PW so I could give it a shot.

The small things such as the punch at the start of the game really make a big difference. Never thought that Conn's codes could help out older hacks.

I only wish that some of the dungeons be edited a bit to allow the game to have much better game play.

[qwertymodo]

If you want to do your own dungeon remodel like PD, be my guest, but I have absolutely no interest in doing so.

[Puzzledude]

I only wish that some of the dungeons be edited a bit to allow the game to have much better game play.

I believe qwerty said once this is not his goal.

Main problem with PW is that it is uncompatible with HM, while the original Tower of the Triforce, which was somewhat in a beta state, was pimped overworlds wise by SePH, but the dungeons were never "pimped", thus this difference between overworld and dungeons. And the incompatibility with HM disallows to just change this and make your own dungeons.

[qwertymodo]

Figured out the Lake Ruins overlay bug.  There's a section of code with a jump table based on the current overworld area, and the code specific to area $70 (the Lake Ruins) contains the code for moving the storm overlay to create the "snow falling" effect, as well as the lightning flash effects.  Originally, it is hardcoded to the "dungeon is open" flag in SRAM because the game would normally disable the storm once the dungeon was opened, so if you happened to be in the state where the "dungeon is open" is true, but "have the master sword" was false, it would skip the subroutine responsible for moving the overlay around, flashing the lightning, etc. but my master sword code had already enabled the overlay at that point, so you got the overlay, but without the movement or flashing.  Replacing the original "dungeon is open" check with a "have the master sword" check and it works as intended (the check to actually open the dungeon is somewhere else entirely and only happens once per screen transition, this one is called once per frame, so there are no unintended side effects).

Code:

fseek($02A4DB)  // Specific fix for Lake Ruins (original hardcoded location for storm overlay)
    lda $7EF359 // Check sword level (instead of check dungeon open flag)
    cmp #$04    // Check if we have the master sword
    db  $B0     // bne -> bcs (bge)

So this means the Master Sword code should be bug-free and will be included in v1.3 as intended, instead of Puzzledude's 1.23 fix by removing it. He felt that it was unnecessary because there was no reason to return to the Icy World after getting the Master Sword, but that's not true. The only Icy World dungeons required for beating the Parallel Tower are Darunia's Cavern and Saria's Gardens. Beating the Tower early to get the Master Sword can make the rest of the dungeons easier, which will give you a large portion in the game with the winter storm gone (and the different music!).

[Puzzledude]

So this means the Master Sword code should be bug-free and will be included in v1.3 as intended, instead of Puzzledude's 1.23 fix by removing it.

I reverted to old code, since this was a "new" bug, which "wasn't there before". But nice that you could debug it.

He felt that it was unnecessary because there was no reason to return to the Icy World after getting the Master Sword, but that's not true. The only Icy World dungeons required for beating the Parallel Tower are Darunia's Cavern and Saria's Gardens. Beating the Tower early to get the Master Sword can make the rest of the dungeons easier, which will give you a large portion in the game with the winter storm gone (and the different music!).

Yes, however the natural gameplay is to solve all dungeons before getting into the final tower. I think the developers made a mistake not to inforce this to the player. Also, the original required 2 climbs for the sword, so naturally players will assume this to be valid in 1.3, while sword 3 and 4 are pretty much of the same power, thus the natural feeling of the players is skipping sword 4 entirely. This sword was considered higly optional in PW. But like said glad you debugged this Lake problem.

[Puzzledude]

Just wanted to let you know qwerty, that I tested this out and it works: thus the master sword debug in hex is this:

at 124DB:
from AF F0 F2 7E 29 20 D0 into
AF 59 F3 7E C9 04 B0.

Once you open the dungeon, you will have a temporary no overlay (in RAM) only, but once you exit into the area, it will be normally snowing, until you have sword-4. Then the snowing is gone permanently.

[qwertymodo]

Thanks for testing. I didn't think to check when opening the dungeon. So I guess that's the last thing to fix.

[Puzzledude]

Thanks for testing. I didn't think to check when opening the dungeon. So I guess that's the last thing to fix.

I don't think you can, or need to. Since the Ether medallion used to open the gate into the dungeon will affect the weather. So because of it, the sky becomes temporarily clear. The storm returns later. I used the same strategy with the Master Sword fog overlay in GoT. When you pull, the overlay is gone temporarily, otherwise the area always has fog (but this is not PW related).

Also, I'm not sure if it is indeed possible to tacle with the Ether opening the gates event: the event first flashes the overlay, then it removes it. So from a debug point of view, the current situation is acceptable.

[qwertymodo]

It was possible for Nintendo to write the code to disable it in the first place, it's possible for me to write the code not to

[Puzzledude]

It was possible for Nintendo to write the code to disable it in the first place, it's possible for me to write the code not to

Nice. Your call then on how to handle this.

[qwertymodo]

On the other hand, possible does not always imply feasible. I'll definitely give it a try though.

[qwertymodo]

Got it

Code:

fseek($1BCD14)
    inc $B0
    rts
    nop

Code:

0x0DCD14
E6 B0 60 EA

[Puzzledude]

Got it

Code:

fseek($1BCD14)
    inc $B0
    rts
    nop

Code:

0x0DCD14
E6 B0 60 EA

I tested this again and it again works. Now the entrances opens and the camera shake effect is on, while the overlay is always on. Great job. This is fully debugged now.

Also, nice that you wrote it in hex as well, since this is how I write edited codes.

[qwertymodo]

Looking at the 1.23 notes:

Basically what's happening here is, that rooms above 292 were no longer an exception, when they should be: thus room 294 with fairies was exiting Link on regular -16 pixels, which is too high, thus his head was seen in the wall.

This is not correct.  In the original game, all rooms above 292 used staircase-style entrances, so comparing the room number to 292 was a simple way of checking "is this a staircase entrance".  The purpose of the original code was to adjust your Y-value on exit so that if you left from a staircase, your Y-coordinate was left alone and if you left from any other entrance you were adjusted up by 16 pixels so you looked like you were coming "out of" the door.  Parallel Worlds does not follow the original rule about rooms above 292 using stair entrances, so I had to do a manual check.  By changing the rule the way you did, you broke this manual check, which re-introduces this bug to all staircase entrances: https://www.zeldix.net/t1107-parallel-worlds-cave-staircase-exit-y-coordinate

The bug you are trying to fix is not due to the Y-coordinate at all, it is a layer priority bug.  The -16 adjustment is exactly the way the original game expects normal cave entrances to behave.  I may consider the 16->8 pixel adjustment, but the room 295 check makes no sense.  If you really wanted to fix it that way, you should have just added room 294 to the manual list.

[Puzzledude]

In the original game, all rooms above 292 used staircase-style entrances

True, however Parallel Wolrds doesn't, which is where the problem is.

but the room 295 check makes no sense

Sure it does: it brings all entrances to the same properties. Which is what I wanted. I didn't want any exceptions, I rather wanted the person to exit anywhere on same properties. Thus the redux from 16 to 8 was necessary.

The -16 adjustment is exactly the way the original game expects normal cave entrances to behave.

Yes, and the original game is wrong, since this is far too high. Namely, Ninteno did not realize, that you can hold the sword while facing left or right and move the player into the cave in such a state: the entering routine will not work, since you must face up. When you now turn up, your Y is far bellow of the normal value and now 16 is substracted from this false value, you then exit around 24 pixel higher from what you normally enter from (if facing up while entering= normal entering). Of course this could be solved with: do not move while holding sword, but I decided not to add this feature.

I may consider the 16->8 pixel adjustment

Because of the previous statement, this is what I found mandatory. Since if on "false entering" the false 24 gets reduced by 8 as well. With the redux we have: 8 (normal) or 16 (false), with Nintendo we have 16 (normal) and 24 (false).

This reduction also fixes the starcase-exits. You no longer exit 16up on starcases, you exit 8up, which still looks ok on starcases. Note: false entering is not possible on starcases. 0 up is not really necessary on starcases, while 16 up is to high for caves. This is why I decided 8up on both, and thus the 295 check makes sense, since it covers all rooms.

But this was my personal choice, you can make it the way you want to.

The bug you are trying to fix is not due to the Y-coordinate at all, it is a layer priority bug.

Yes, I'm aware, however as you can read above, this is not the only problem.

[qwertymodo]

If you wanted to change the 16 pixel adjustment to 8, all you needed to do was change $10 to $08.  The only thing you accomplished with the room 295 check was re-breaking staircases.

Edit: Ok, I see your argument now about 8 pixels looking ok for staircases, I suppose we can agree to disagree on that. I'll probably implement your 8 pixel change, but keep the staircase check.

[Puzzledude]

If you wanted to change the 16 pixel adjustment to 8, all you needed to do was change $10 to $08.

Exactly. However the fairy cave is room 294.
Keeping the check on 292 would include this cave as staircases.

The only thing you accomplished with the room 295 check was re-breaking staircases.

Yes, and at the same time fixing room 294, while the "broken starcases" basically were not really broken, they were just -8 instead of 0 (this could be called a bug though). However the real bug is, if the starcases are -16.

So you see what I did: instead of -16 (normal), -0 (exceptions), I've made it -8 on all. Now it doesn't matter where you exit (cave or staircase), nor does it matter if the rooms above or bellow 292 are caves or staircases. While the "false entering" on caves is -16.

Do note: you have free hands here. You can make it the way you want to.

[qwertymodo]

If you wanted to change the 16 pixel adjustment to 8, all you needed to do was change $10 to $08.

Exactly. However the fairy cave is room 294.
Keeping the check on 292 would include this cave as staircases.

PW 1.2 removed the check on 292. That's why I said it didn't make sense to check for 295. The list I made to replace the 292 check already treated 294 as "not a staircase". But in any case, it's not really worth arguing about, it's fixed and that's all that really matters, I'm just posting my progress as I go.

[Puzzledude]

PW 1.2 removed the check on 292.

You know I tested the game and when playing 1.2, I noticed a problem with the fairy cave (exiting too high). If you play the 1.1 version, you can see Link exiting in a normal way. This was the only reason I tackled with this. I saw a (new) problem, which wasn't there before, and I wanted to fix it.

This is why you always need to test later to see how it is in practice. Version 1.1 has the fairy cave exit ok, 1.2 has not.

So ironically in practice keeping the 294 to be regarded as staircase and thus exiting on 0 looks better as if you exit from what the cave should be officially using.

But of course you can still fix the problem by putting the wall above the cave to use the "in-front" option to hide Link's head in the wall when exiting.

But in any case, it's not really worth arguing about, it's fixed and that's all that really matters.

I'll say it again, you are supervisor, you can make it the way you want in 1.3.

I was the supervisor for 1.23 and made it, the way I thought is the most debugged. My priority was thus debugging. Master sword ASM was bugged at the time, removing it meant debugged. Link's head was in the wall (ie bugged), so I made somwthing which debugged the problem. Irronically both these problems were not present in 1.1. This is why testing is needed. If you test you can see Link's head is not in a wall in 1.1, but indeed he is exiting the fairy cave too low (on 0), thus keeping this cave to be under starcases was actually beneficial.

I could fix the upper wall's properties, but there are many such exits, where Link could exit in a wall, since he is exiting too high. My solution was to thus always exit him on -8 on all rooms and automated exits with no exceptions.

A fine example is also a cave in the Ice beach. You see, you can not fix the in-front priority as the cave uses a "short" wall. Link must not exit on -16 here. His head will be in the upper fence and even the upper floor (while the floor can not be on infront properties), since the cave entrance is using a wall not much higher from the size of the cave. Imagine you make a "false entering" here, which lands Link on -24.

Thus putting the automated cave exits of PW to what ALTTP was using, is not necessarily debugging, which can be determined through testing.

I namely tested the entire 1.23, and entered and exited all caves and staircases in the game without (visual) problems.


But it should again be noted, that this was just my method of debugging. You can can make it the way you want in 1.3.

[Puzzledude]

Just an informal overview:

Let's first take a look at version 1.2,
and then 1.23 and then the old 1.1:

1.2 normal exiting (-16) (bugged)



1.2 side entering+up



1.2 abnormal exiting (-24) (bugged) This is much too high even if you make the upper wall "on-top", correctly hidding the person (this happens on side entering+up)



1.23 normal exiting (-8) (not bugged)



1.23 abnormal exiting (-16) (not bugged) Upper wall was put to "on-top" and person is lower (before it was -24)



1.1 normal exiting (-0) (not perfect but not bugged)



1.1 abnormal exiting (-8) (not bugged)



As you can see the version 1.2 is the only one with the problem. But there are many ways of solving it.

[qwertymodo]

Well, that definitely confirms that I'll go ahead and switch to the -$08 positioning.  Sorry, I really didn't mean to turn this into an argument, my original post was just supposed to be documenting my progress and the reasoning behind my original code.  I do appreciate the work you put into 1.23.  I've merged most of the changes already (still trying to figure out what I want to do about the pyramid ambient sound, since it is tied to Zora's Fountain).

[Puzzledude]

Well, that definitely confirms that I'll go ahead and switch to the -$08 positioning. Sorry, I really didn't mean to turn this into an argument, my original post was just supposed to be documenting my progress and the reasoning behind my original code.

I really don't see this as an argument. Do note: (like I said before), you are the supervisor for 1.3. Thus you can do things the way you want to. You can make it a -16, or a -8. You can make staircase exceptions or not etc etc. I think no one would oppose you making all auto-exits on caves, staircases and houses on -0. So this is sort of a matter of taste.

still trying to figure out what I want to do about the pyramid ambient sound, since it is tied to Zora's Fountain

Yes, this is a problem, since you see, this is one and the same area (if you look this up in Hyrule Magic). My choice in 1.23 was to turn the sound off for both areas, but again you can leave it on for both or off for both. Again the choice is yours.

The same is valid for the church fix. My method was to manipulate 16x16 tiles (middle size squares), yours is to manipulate 32x32 tiles (biggest size squares). Again your choice what to do in 1.3.

[MikeRL]

You need beta testers? Where do I sign up? I have plenty of time to kill, and I actually like Parallel Worlds. I've replayed v1.23 a few times, and have a keen eye for bugs.

[qwertymodo]

I will need testers, but it isn't really ready for that yet. When 1.3 is ready, I'll post an announcement with a call for testers.