General ASM Help topic

Thanks, that's great

Well I found a further bug - you throw anything that flies (boomerang, sword beam...) and change the inventory to the ice rod, the boomerang will create ice tiles as well. My check there isn't sufficient but easy to fix.
Will do that asap with your files.

I was able to create ice in dungeons:



It works on shallow water, the problem however is deep water (swamp palace). The stairs when you jump inside trigger swimming and there is no way to get the 03E8 to check for it. When you use the rod, the tiles directly in front of the stairs get icy (this triggers swimming) but then nothing and you can walk on the water. I see no chance to fix this. So I guess we must renounce on icing dungeons except anybody gets an idea here.

Edit: checked your games and it isn't slippery (but I guess I can turn it on). One major problem however is that I cannot find a ram code to prevent making ice tiles when e.g. the boomerang is on the fly and you switch to the ice rod...

Here are the values to make your rom slippery:


$00/886E BF 59 94 0E LDA $0E9459,x[$0E:95DC]
0e/95dc=pc 07/15dc, make a 0e instead of 00

From the debug perspective, it is best to prevent freezing as much as possible. So turning it of im dungeons is a wise idea. I also don't know why freezing affects the non-water tiles sometimes, specially if you change the type 14 attibute (ice floor) of the tile, to 9 (shallow water). This would make a Shallow water Rod (which has the best possible collision, since deep-shallow water make no collision bugs, while ice-shallow water and even ground-shallow water make it).
 
If ice type, there's a false collision with shallow water (Alttp engine will not allow this collision with no odd behaviour of the main sprite). If ground type, there's a false collision when swimming left or right if only one horizontal line is iced. Link will not jump out but swim into ice and into shallow water, if it is iced.
 
So shallow water type is the best (or gorund type, but no flippers), but then you can freeze walls and other tiles also, if multishooting in one more directions.
 
Seems like when vram transfer is happening, the second shoot will afect non water tiles. This is just my guess from testing.

In dungeons the animations blocktypes are changing depending on your current blockset!







I haven't fully documented the blocksets and their blocktypes (where you change them in hex) but it's fully possible to edit them as I've done it already. You can have for example, shallow water, deep water allongside waterfalls, lava that hurts when you walk on it, conveyor belts and ice all in the same blockset if you want!

You can edit them out in hex using the method that Spane found out a while back!

Spane wrote:Hi
I've figured out a way to change the dungeon block typs via hex. It's really easy.
As an example. Go in a dungeon and in the dungeon piece editor. Look at the first line of tiles and note the block types.
01 01 01 00 02 01 02 00 01 01 02 02 02 02 02 02
Now open you rom in a hex editor. I prefer Hex-Editor MX.
And now search for the 16 variables. The editor find the variables by 71859.
And now chance as an example the first 01 to 00.
Save the rom and go again to the dungeon piece editor. You have changed successfully the block type.
For the rest of the block type, it will work in the same way.
I hope I've helped you. More freedom in editing dungeon we come.

Greetings Spane

^^ The first line in red is the animations that change between dungeons (depending on the current blockset)
The second line in blue are the general dungeon animations (that don't change between the blocksets)
The third line is the animation for the pegswitch blocks and the hammer pegs (also don't change between the blocksets)

You see, editing those actually gives you more freedom when you edit your dungeons! You can trully remodel them as much as overworlds in that sense!

Cool, thanks Seph :)However this patch has more bugs than a rotten corpse what makes me to renounce on many things.

Here's what I built upon PuzzleDude's fix:

removed dungeon and shallow water to be affected from ice shoot (too buggy)
involved:
7E/008c-00 = dungeon/cave
7E/03E8-09 = shallow water
- I renounced on shallow water since Potentialing wants the deep water to get items before Flippers or so. Freezing shallow water would make no sense for riddles.

fixed bug that leaves an icy trace by boomerang when switched to ice rod while on the fly
7E/03A3-06 ice rod only shot - the ice rod will not freeze water until boomerang returned.

fixed collision with shallow water at 0e/fc90= pc 0x77c90

made new tiles by PuzzleDude slippery
0e/95dc=pc 0x715dc, make a 0e instead of 00

Puzz, can you check whether there are further probs?

Sure, all of these choices are correct. Maybe it was indeed the problem of icing shallow water, that had those effects. Usually a simple testing of all possiblities is involved. Will test it now, to see how it behaves.

This is much better. The only problem I could find is the fast shooting of the rod, which can sometimes freeze the tiles, it shouldn't (I think this can be solved by making Link use the rod slower). For instance shooting right on the water and then fast up into wall, can freeze the wall, which can make you then walk of-screen. So the problem are 2 shoots at once on screen (should be only 1 shoot at once, can be achieved if shooting slower).
 
One more idea. The rod currently freezes tiles type 8. How can I change this into type 3 (solid unused). I'm guessing this is one byte change only? With this I can make a brand new object, passable only if the ice rod shoots it. Since this object would be on certain spots only and will take no more than 4 small squares, the possibility of bugs is zero, while still using your icerod code.

Wow, there has been so much progress since I last checked, I don't even know what to say other than "amazing job". I noticed, in "puzzconngfx", that you lose all ability to jump off northern ledges. Before I can suggest anything, though, I need to learn how this code works, so I'll spend today analyzing that hex. (I'll have to find out how to convert it first, though.)

Regarding the issue with dungeons, I'd actually like to get it working in dungeons, but it's probably a rom-specific issue, so I'll have to learn how to do that myself. (Alternatively, ASM can set variables you can quickly change at the top of the text document. If I ever find out how to fix the issue, then I'll try to make it configurable for everyone.)

Found the tile which controls, which type to freeze  .

It is here (start of main code)
9D E4 03 A8 AD 8C 00 D0 01 6B AD A3 03 C9 06 F0 01 6B AD E8 03 C9 08

The last byte 08. I've changed it to 03, then tried 01, while changing the type of water to 03, 01. Works.

This basically means we can use the icerod code to make something alot more stable. Freezing all water objects (and in dungeons also) will affect the game to much to completely avoid bugs or odd situations. However the new fix2, which excludes the dungeon and shallow water is a giant step forward into debug.

I will disappear to vacation in 2 days and therefore will not work further on this. I'd be happy if you can progress this patch together...

@ Puzzledude: the disassembly of the first part is:

Code:


org $0efba0

STA $03E4,x   ; regain overwritten values by jsl
TAY                  
LDA $008C    ; check if 008c is 00 (dungeon/cave) if yes go back to game
BNE $01    
RTL          
LDA $03A3 ;(check if rod is fired and not boomerang, bugfix)
CMP #$06    
BEQ $01  
RTL              
LDA $03E8 ; check if water tile 08
CMP #$08    
BEQ $08  
LDA $03E7 ; check water tile second shoot
CMP #$08  
BEQ $01    
RTL              
LDA $0303 ; check rod is used
CMP #$06      
BEQ $01  
RTL                
LDA $0304  ; check rod is used #2
CMP #$06        
 BEQ $01  
RTL                
 TXA        
STA $7ED004

to disable the second shoot and enable the check for block 3 you simply need to rewrite pc: 0x77bb9

LDA $03E7 ; check water tile second shoot
CMP #$08  
to
LDA $03E8;
CMP #$03

Hex
ad e7 03 c9 08
to
ad e8 03 c9 03

This will disable the second shoot icing and enable your tile 3 read ;)both problems solved with one catch.

@Potentialing:
Thanks a lot
I don't know what you mean by jump off northern ledges.
I was halfway enabling the feature to dungeons (difficult since it needs a further calculation of the coordinates). Succeeded, but realize it isn't possible to implement due to following reason:
When there is water in dungeon only the tile in front of a stair from which you jump into water get a 08, other water tiles remain 00. So you are only able to freeze the first tile in front of the stairs. Freezing those will skip the swim tiles and you walk on water. To make the code work in dungeons you'd need to reprogramm all water tiles to have a 08; I dunno how this works.

The following code is not included in the puzzconngfx since I rennounced on dungeons due to the problems arose.
At pc:0x77be0 you find ad b8 00 this is a check for dungeon, if you are in, the coordinates are calculated at pc 0x77ca0

If you can make dungeon swimming tiles work, you need to copy the code again into the current project.

I updated the hack and it contains the changes above (enable unused 03 blocks, by disabling 0e47 read). Does it fix the wall freezing bug? It does not disable the second shoot from icing tiles (as I thought first) but since there is now much less calculation needed to be done, there's a good chance that it doesn't freeze the wall anymore... but you need to check it yourself since I am not entirely sure that I understood correctly how you created the bug.

Potentializing, I also enabled the dungeon ice shot. Maybe you can enable via Hyrule Magic the dungeon water tiles to have the property 08?
Maybe Seph's documentation of blocktypes on previous page help?

For some unknown reason the code can not render the second shoot correctly. Even if I turn the second shoot off completely in hex (AD E7 08 etc to FF FF FF etc). This is easy to test. Fire the icerod into deep water on the right and make a second shoot to the left.

Once the first shoot starts freezing, the second one will freeze walls, normal floor etc. Which is strange, since I redefined the second shoot to freeze only type 3 tiles (and turn it off completely also). If we swap this, and make first shoot to read type 3 and second type 8, it works better. 2 shoots are needed to freeze water, but then it also bugs out later.

I've also tried to change the second code AD 03 03, and AD 04 03, which controls the second shoot of ice rod, with the same result.

It seems like when the transfer to vram is happening (which is once the deep water is freezing), the code reads all icerod shoots on screen, no matter how many, and it transfers the ice tiles on all shoots and on all tile types, it just needs type 8 to activate. It also resets to normal once all shoots on screen end (it then again looks for type 8 only).

Maybe we need this:
AD 04 03 , load second shot of ice rod
check if vram transfer is happening, if yes, branch to EA, which is NOP,
check if vram transfer is happening, if no, branch no EA which is NOP, just to be save.
This should turn off the second shoot completely, and fix the bug.

I see a way fixing this by disabling icing at all when two shots are given. read 08e7 if there is a 08 return to game:
add this somewhere after the cmp 03 or so:
ad e7 08 c9 08 c9 08 d0 01 6b

This is not elegant since the first shot will then not ice as well anymore, but hej, how many times will you shoot the ice rod twice?

This new code doesn't seem to solve it, since the entire second shoot is somehow ignored during vram transfer. The D0 01 makes you freeze all objects, if changed to F0 01, its the way it was before. Or maybe I'm inserting at the wrong place?
 
Meanwhile I was however able to come up with the brand "new" object in Alttp (tile type 3 which is also new, since it was never used), the Water Rock. A blue rock, which can only be passed with the ice rod (works in dark world also).
 


 
 
As you can see here, the bug is altogether reduced, since only one block is being frozen, while carefully placed within the fence, preventing any possibility of a bug (second shoot will not hit anything at the same time as the first one, since Link must stand next to a rock to hit it, so vram transfer is immediately started and canceled).

Looks really awesome! Seems you can get something absolutely amazing out of this patch :king: 

Explaining it is maybe complicated, but I try. The first instruction
9d e4 03 stores the value to both, 03e7 and 03e8 in dependence of the x register. So I set 03e7 to 00 before 9de403 is executed and a value different to 00 (like 08) is stored to 03e7.
I made then a check if the 03e7 is still 00, if it got rewritten by 9de403 it means the second shot is used and I skipped the code.

So it seems I can go into vacation now and can expect something exciting when I return :p
Say, is it possible to give all deep water tiles in dungeons a 08 so that the dungeon code works as well?

Fantastic, it works  . If we assume you have limited amount of green magic, this is actually debugged. I will probably go with the Water Rock, but now it doesn't have to be walled in the fence.
 
I tested this new code, by abusing the rod on a unlimited green magic cheat, and could only freeze a tile or two, who should't be frozen, which is a lot lot better then before.
 
Another debug will then be to simply not give the half magic, so that the player would use the rod carefully, preventing bugs altogether.
 
In GoT I have a Lava area in Part2, so this code could fit in perfectly, but instead of freezing water, it would turn lava into solid ground. So I just need to calculate how much green energy is needed to come through lava to the island, taking the shortest rout (while swimming is disabled). This will prevent any bugs, since you will have to come through with minimum shoots; or return to the cave with magic refill otherwise.

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

Regarding the dungeons. You can give all indoor deep water a type 8 value, but only in hex. However, I think that all water in the dungeons is already on type 8, since this is the only type, you can swim in. While all shallow water is type 9 in dungeons also. So the code is probably not working in dungeons, because of the specific stairs, which make Link jump into the water, but this is the same as jumping in the water in the overworld, so it is strange why indoors is not responding. (I never tested the rod indoors though).

I'd not limit the player on magic use due to one or 2 bugs. They'll use the rod carefully anyways since it draws magic - and if they are on a place where they need the magic they would never shoot as mad
And even if one tile gets frozen that shouldn't... so what?

I may look further to prevent those small remaining bugs when I am back.

Ok then I leave the indoor water tiles to potentialing... I cannot do anything here anyways since the hex must be changed when building the dungeons, and this is different in every hack anyways.

Actually I found this minor problem on further testing, easy fixable.
 
Quote:
Explaining it is maybe complicated, but I try. The first instruction
9d e4 03 stores the value to both, 03e7 and 03e8 in dependence of the x register. So I set 03e7 to 00 before 9de403 is executed and a value different to 00 (like 08) is stored to 03e7.
I made then a check if the 03e7 is still 00, if it got rewritten by 9de403 it means the second shot is used and I skipped the code
 
Because of the above the same (old) bug appears if the second shoot touches tiles with type 0. This is fixable in HM, by simply putting it to type 72, same as 0, but not the same value.
 
The very first bytes of the code 9C E7 03, have no value 00. So I couldn't change this value 00 to for instance 06 (this is same as 00, but unused), so the second check would then be: "check if the 03e7 is still 06". Putting this second check (and the check at the very beginning) to 06 would prevent this minor bug (same as old one, just reacts only on type 0 on second schoot). If putting the both checks to 06, the bug would affect the 06 type tiles on second shoot, but nothing is type 6, or can be put normally to type 0.
 
But this is not necessary, since you can do it vice versa. Put all type 00 to type 06 or 72. It is just being mentioned, since type 00 for normal ground is default.
 
EDIT
The rocks on the water must also be constructed in a specific way. A 16x16 tile must consist of 4 rock tiles, but not 2 water or 2 rock tiles (must never have 2 water tiles), otherwise it will get frozen by default.

I think I will just find all type 0 in the 8x8 and change them to type 72 (since this is the mirror of 00 - same thing with different value), as a part of the hex code, to finish the ice rod patch to its final state, so you can ejoy the vacation.

Ah no... not that complicated

I now deleted again the set to zero of 03e7 and made a cpx #04 beq #01instead
Means, if the x value is 4 (that triggers the store to 03e8) the code proceeds, if it is 3 (that triggers the store to 03e7) or anything else it returns.

Should work now bugfree (I hope)

Perfect  . I could not find any bugs, even if heavy abusing the icing in multiple directions and on multiple tiles. The second shoot is always ignored (and this is the way it must be). Beautiful, really. I have so many versions now, this final one is ice rod fix-4. I will make a final version in hex also, and in ips.
 
I think when players will one day see such a complex thing as freezing water to ice, or lava to normal ground without bugs, they will be astonished; similar to the multi sprite of Parallel Universes.
 
EDIT
The final fix (or fix-4) has the same core as fix-2, but the new code is added before the third AD, which is this E0 04 F0 01 6B (which is cpx #04 beq #01). This CPX is one fine command.

haha* then I can go into vacation merrily since also the pu-link tilesets patch is finished.
This icerod patch is really something awesome since it opens complex new possibilities and riddles (if you get it before flippers) and now that you even get lava frozen it can be needed also at any point in a game that has lava tiles. And your new waterblocks make it all even more fantastic!

I only wish that it can also be used in dungeons...

Regarding the dungeons. You can give all indoor deep water a type 8 value, but only in hex. However, I think that all water in the dungeons is already on type 8, since this is the only type, you can swim in. While all shallow water is type 9 in dungeons also.

No I tested with the rod. Only the tile directly in front of the stairs is 08, the rest is 00. But it is good to know that you can also set the 00 deep water blocks to 08. Maybe you have the time to test the dungeon rom?

I will also test the dungeon rom, once I have all the files sorted out for overworlds. I've also seen this patch checks for both type 08 (water) and type 03 (water rock), which is interesting, since this was meant to be separated; so I'll make some more versions (like only water, only rock or both).
 
I've checked deep water in dungeons (but only via HM), and the deep water on bg2, it says all type is 08? So I guess I have to test it in-game, to see what the problem is.


PS
Regarding overworlds. Because of this code, I can also make a "Ground Rod" (changes deep water to ground), a "Water Rod" (changes deep water to shallow water). Can also change lava (red water) to ice, or lava (red water) to ground; or lava ground tiles (type 13 = same as indoor spikes) to normal ground. Can also make a "lava rock" along with "water rock" etc.

I included 03 to all roms since they aren't used in the rom, so it won't hurt having it in the code. And I'm already confused with all the versions...
with 2 overworld and 2 dungeon versions and 3 times different (03,08, both) you end up at 12 patches...
But do as you wish!  

Dungeons:
I tested the water again and when waving the rod over it it says 00... only at the stairs it is 08.
I was testing shallow water (temporarily gave the code a check for 09 instead 08) and works perfect

btw, if you mess around with the dungeon code, take care of the jmp back at pc 77cd5. This must point to the 18 currently at pc 77c0e...

Quote:
with 2 overworld and 2 dungeon versions and 3 times different (03,08, both) you end up at 12 patches
 
I guess I've auto excluded the dungeon versions. Also will probably go just with the final version of overworlds (it was just meant to not freeze water, if the special object is in use, but rather use it only at that object). So I only had 2 main versions in mind.
 
Regarding Dungeons. Found what the problem is. The water is on bg2! So you freeze only the first tile, which is in bg1. Then you dont walk on water, but on lower part (as if no water), since freezing the stairs, will corrupt the passage to bg2.
 
That's why it says type 00 (of the lower floor, which is type 00). So you should address the bg2 (water) from bg1 (place where you stand before jumping in). I don't know if this is possible to do (because the whole point of bg-s, that bg2 is ignored, while on bg1. This is why you can make a bridge and go "under" it (not possible on overworlds).
 
EDIT
My guess would be, that in dungeons you can only freeze shallow water (since it is as an object on the same bg as where you stand). This means you can freeze it, if both (player and water) in bg1, or in bg2 (lower ground). But I don't think it goes for the deep watercorridor, because the player is on bg1 and can not address bg2 (water) before jumping in (but you can not use the rod, while swimming).
 
This is why you see type 00 in RAM (because you don't address water at all). Freezing the passage to bg2 (water), will therefore give you a typical bg-bug = going into the water corridor as if no water would be there.
 
 
IDEA
There's one more option. Do not build water as a water corridor, but as plain water object. This is somewhat unaesthetic, since no such transition was planed by Nintendo. They only planed solid ground going into shallow water. You could for instance make a new tile (adopt the gfx) which would be a transit from shallow to deep water (but on the same bg, so no water corridors).
 
So I guess it is possible to do, but no water corridors must exist in the game, only all water on the same bg. So there must never be a staircase into the water, since this changes the bg you are on.