 |
|
 |
|
| YI hacking FAQ v2 (updated 2013-3-18) - Ask questions here! |
|
Forum Index - Non-SMW Hacking - Yoshi's Island - YI hacking FAQ v2 (updated 2013-3-18) - Ask questions here! |
|
|
|
|
| Posted on 2012-01-06 06:52:06 PM |
Link | Quote |
|
|
If you happen to be using that space after the graphics for other data, using 1 will overwrite that data, but using 11 will leave it unchanged.
|
|
| Posted on 2012-01-06 07:00:33 PM |
Link | Quote |
|
What exactly is your question? If you really want to know why, then it's because it has been programmed to behave like that. The difference and advantage of two different compressing methods is simple: The first compression method, which overwrites everything after the ending address up to 0x1F957F with FF-bytes is for when you do not use the free space the compression adds to the ROM. If you use the free space after the graphics, however, it's good to have another method, which does not overwrite all the space after the ending address or else you would be forced to save that data somewhere else.
*Edit*
Ninja'd, damnit 
|
| Last edited on 2012-01-06 07:01:43 PM by Yoshis Fan. |
|
| Posted on 2012-01-09 06:31:50 PM |
Link | Quote |
|
Quick question:
Whenever I try to load my SMC rom to Golden Egg, it gives me the following message:
"The loaded ROM's country code is other than the North American version".
I tried to convert the SMC to an SFC by changing the file name, but it didn't work. How can I resolve this?
|
|
| Posted on 2012-01-09 09:23:30 PM |
Link | Quote |
|
|
I'd assume that error means you need the North American version of the ROM, and the version you have is something different. Did your ROM have "(U)" in its title when you first found it?
|
|
| Posted on 2012-01-21 06:47:07 PM |
Link | Quote |
|
Is there a way to make the Piranha Boss battle compatible with Sprite 0x048? Since Sprite 0x171 determines the Y-position of the boss battle, I cannot use that one in order to immobilize Yoshi; thus I want to take 0x048. It actually works, but the problem is, when I place 0x048, it triggers Kamek twice. So can Sprite 0x171 be edited, so Kamek is not triggered there, so he is triggered by 0x048 only? I hope it's all about NOPing some code...
*Edit*
Sprite 0x171 obviously has a built-in Sprite 0x048. When I NOP the three bytes at ROM 0x2A84E [A9 48 00], Kamek will not appear twice. But since all effects of 0x048 are gone then, Yoshi will be able to move shortly before the battle starts making it possible to get close to Piranha and automatically getting hit while Yoshi is still unable to move. (Kind of suicidal to move near Piranha, but still annoys me, that it's possible.)
|
| Last edited on 2012-01-22 07:36:07 AM by Yoshis Fan. |
|
| Posted on 2012-01-22 08:47:32 AM |
Link | Quote |
|
Can you provide an IPS?
Both 0x048 and 0x171 are Boss controllers-
0x48 would change the behavior during Milde and Tap-Tap,
0x171 would require that a JSR/JSL be removed.
|
|
| Posted on 2012-01-22 09:28:45 AM |
Link | Quote |
|
Alright, here is the IPS file:
NavalPiranha.ips
Also, for easier testing, here is a SNES9x savestate, so you don't have to play through 3-8:
NavalPiranha.000
Changes done (all the Offsets are ROM) :
0x0A6A3 = [EA EA EA EA] (Prevents wall from rising)
0x0A6D7 = [EA EA EA EA] (Prevents wall from rising)
0x0A710 = [F0] (Prevents wall from rising)
0x2A7F6 = [B0 02] (Makes battle start at X-position 0x2B)
0x2A84E = [EA EA EA] (Disables the built-in 0x048)
Modified Piranha boss room
|
| Last edited on 2012-01-22 09:35:33 AM by Yoshis Fan. |
|
| Posted on 2012-01-22 11:12:06 AM |
Link | Quote |
|
This skips over the dialogue and transformation for 0x171 Kamek.
ROM
0x171 Kamek won't talk
0x065DD4 = [0x6B]
0x065DAB = [0x80]
0x02A862 = [0xEA 0xEA]
Revert
0x02A84E = [A9 48 00]
Not changing the 0x065DD4 makes the other Kamek(0x171) not talk,
but still sweep across the screen while the other is talking. -will mess up the text,
it looks neat having both Kameks out of sync.
|
| Last edited on 2012-01-22 11:13:38 AM by tehaxor69. |
|
| Posted on 2012-01-22 03:36:21 PM |
Link | Quote |
|
Well, thanks, but that's not the right solution
...
Maybe, it is possible to immobilize Yoshi without triggering Kamek at all. So a custom Sprite is activated by 0x171, which is not 0x48, but a similar one. Immobilizing Yoshi is essential.
Also: Another solution is possible:
Making object 0xC compatible with the Sewer tileset.
Sadly, I have already used the space from 0x8BC00 to 0x8CBFF in the AllGFX.bin, altering the 3rd GFX set used for Sewers is hardly possible.
A custom object can also be made, which is similar to 0x2B. 0x2B is actually like 0xC, but uses different Tilemaps. Another object using different Tilemaps would work well for GFX set 0x44 (which is the unused one I used). Also, the palette of that object must be altered. Once it's pounded, the stone sewer BG must be shown. I think of something like this:
Once that one is pounded, Yoshi is immobilized because of his "ground pound" status and the battle starts without needing an additional Sprite.
*Edit*
@tehaxor69:
Could you please collect all the code related to object 0xC?
The pointer for object 0xF6 is at SNES 0x1287EA, so the pointer for object 0xC should be at SNES 0x128616. The pointer is -1, so it points to ROM 0x91554.
The weird thing is, the pointers for objects 0xE and 0xF are the same...
*Edit2*
I've isolated the code, but sadly it neither controls the metatiles used for the object, nor does it control its behaviour. Actually that was obvious from the beginning on, since other objects use the same code.
Code00097250 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00097260 64 17 86 24 86 21 86 27 c2 10 85 22 85 1f 85 25 d..$.!.'Â.."...%
00097270 a9 ff 7f 85 19 20 8b f0 e2 30 6b ff ff ff ff ff ©ÿ... .ðâ0kÿÿÿÿÿ
00097280 ff ff ff ff ff ff ff ff ff ff ff 64 28 64 2c 64 ÿÿÿÿÿÿÿÿÿÿÿd(d,d
00097290 9b e2 30 64 14 20 ea f0 c2 20 e2 10 4b f4 2e 86 .â0d. êð â.Kô..
000972a0 a5 2c c5 19 90 0b a6 27 da da ab a5 25 48 e2 20 ¥,Å...¦'ÚÚ«¥%Hâ
000972b0 6b a5 28 29 01 00 d0 0b a6 24 da da ab a5 22 48 k¥()..Ð.¦$ÚÚ«¥"H
000972c0 e2 20 6b a6 21 da da ab a5 1f 48 e2 20 6b 88 86 â k¦!ÚÚ«¥.Hâ k..
000972d0 1d bf 00 80 7f 85 12 e2 30 60 ff ff ff ff ff ff .¿.....â0`ÿÿÿÿÿÿ
000972e0 ff ff ff ff ff ff ff ff ff ff c2 20 a5 1b 29 ff ÿÿÿÿÿÿÿÿÿÿÂ ¥.)ÿ
000972f0 00 0a 85 00 e2 20 a6 1c 20 16 f1 86 1d bf 00 80 ....â ¦. .ñ..¿..
00097300 7f 85 12 e2 30 60 ff ff ff ff ff ff ff ff ff ff ...â0`ÿÿÿÿÿÿÿÿÿÿ
00097310 ff ff ff ff ff ff e0 80 b0 12 bd aa 6c 29 3f d0 ÿÿÿÿÿÿà.°.½ªl)?Ð
00097320 3b ee 4d 0d ad 4d 0d 29 3f a8 d0 16 c2 30 22 77 ;îM.M.)?¨Ð.Â0"w
00097330 f1 12 e2 10 a9 f1 01 1b e2 20 a9 10 48 ab 5c 8a ñ.â.©ñ..â ©.H«\.
00097340 f1 12 b9 4e 0d f0 0c c8 98 29 3f a8 cd 4d 0d f0 ñ.¹N.ð.È.)?¨ÍM.ð
00097350 15 80 ef 98 e6 97 9d aa 6c 99 4e 0d c2 30 29 ff ..ï.æ..ªl.N.Â0)ÿ
00097360 00 eb 0a 65 00 aa 60 ff ff ff ff ff ff ff ff ff .ë.e.ª`ÿÿÿÿÿÿÿÿÿ
00097370 ff ff ff ff ff ff ff 80 fe 6b ff ff ff ff ff ff ÿÿÿÿÿÿÿ.þkÿÿÿÿÿÿ
00097380 ff ff ff ff ff ff ff ff ff ff 22 50 f2 12 8b 4b ÿÿÿÿÿÿÿÿÿÿ"Pò..K
00097390 ab 22 a8 f2 12 c2 20 8b a2 70 da ab a2 00 9e 9e «"¨ò. .¢pÚ«¢...
000973a0 44 e8 e8 e0 78 90 f7 a2 7f da ab c2 10 a2 00 82 Dèèàx.÷¢.Ú«Â.¢..
000973b0 9e fe 7d ca ca d0 f9 ab a2 0e 00 9e 4e 0d 9e 5e .þ}ÊÊÐù«¢...N..^
000973c0 0d 9e 6e 0d 9e 7e 0d ca ca 10 f0 e2 30 9c 4d 0d ..n..~.ÊÊ.ðâ0.M.
000973d0 a9 80 a2 7f 9d aa 6c ca 10 fa 64 97 c2 30 a9 01 ©.¢..ªlÊ.úd.Â0©.
000973e0 00 85 2a 85 2e 64 15 e2 20 a4 99 b7 32 85 15 c8 ..*..d.â ¤.·2..È
000973f0 b7 32 85 1c c8 b7 32 85 1b a5 15 f0 43 c9 ff d0 ·2..È·2..¥.ðCÉÿÐ
00097400 5f a5 1c 30 2c c2 20 29 7f 00 0a 0a aa b7 32 9f _¥.0, )....ª·2.
00097410 00 7e 7f c8 b7 32 9f 01 7e 7f c8 b7 32 9f 02 7e .~.È·2..~.È·2..~
00097420 7f c8 b7 32 c8 c8 eb 29 ff 00 c9 ff 00 d0 d8 e2 .È·2ÈÈë)ÿ.Éÿ.ÐØâ
00097430 20 e2 10 a2 7f bd aa 6c 9d 6a 6d ca 10 f7 ab 6b â.¢.½ªl.jmÊ.÷«k
00097440 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00097450 8b 4b ab c2 10 a0 00 00 a2 00 00 86 99 64 02 bd .K«Â. ..¢....d.½
00097460 05 8b 85 04 a9 00 c6 02 10 11 48 a9 07 85 02 5a ....©.Æ...H©...Z
00097470 a4 99 b7 32 85 06 c8 84 99 7a 68 06 06 2a ce 04 ¤.·2..È..zh..*Î.
00097480 00 d0 e3 99 34 01 c8 c8 e8 bd 05 8b d0 d4 ad 50 .Ðã.4.ÈÈè½..ÐÔP
00097490 01 8d be 03 e2 10 ab 6b ff ff ff ff ff ff ff ff ..¾.â.«kÿÿÿÿÿÿÿÿ
000974a0 ff ff ff ff ff ff ff ff a9 00 85 02 c2 30 a2 00 ÿÿÿÿÿÿÿÿ©...Â0¢.
000974b0 00 86 03 bf 1a d6 4c 29 ff 00 f0 27 a8 bf 1b d6 ...¿.ÖL)ÿ.ð'¨¿.Ö
000974c0 4c 85 00 ad 36 01 0a 65 03 aa bf 1d d6 4c bb a0 L..6..e.ª¿.ÖL»
000974d0 00 00 97 00 1a c8 c8 ca d0 f8 a5 03 18 69 23 00 .....ÈÈÊÐø¥..i#.
000974e0 aa 80 ce e2 30 6b ff ff ff ff ff ff ff ff ff ff ª.Îâ0kÿÿÿÿÿÿÿÿÿÿ
000974f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Pointers are corrected in this sample; also the FF-bytes do not belong in this an have been set for better orientation.
Also, there must be another pointer table in the ROM, which is for the tilemaps and behaviour, then, no?
|
| Last edited on 2012-01-22 06:20:21 PM by Yoshis Fan. |
|
| Posted on 2012-01-24 07:42:20 AM |
Link | Quote |
|
Sorry for doublepost, but now I'm up with another problem: The Kamek hijack patch. I've modified the patch a small little bit, as you can see below. But applying the patch will make Kamek only appear in the background from when Sprite 0x1FD is executed. The sound, when he attempts to attack Yoshi is played, but he does not appear in the foreground. Is the code looped so the Offset is increased numerous times? I've tested with the horizontal level 0x34 of the original game.
Applying the original patch, as said, will apply Sprite 0x1FD's effect forever from when Yoshi gets near Sprite 0x1FD, even in levels where no 0x1FD is placed.
I assumed, that $701FF4 is responsible for that since the Kamek code checks if $701FF4 is #$0001. And because the value is never set back to #$0000 the eternal offset can be explained.
I don't know the reason why this patch below does not work...
Code;Hijack Kamek routine, needs to be the same with all 3 codes
ORG $03E3BC
JSL $BFFCE4
NOP
ORG $03E841
JSL $BFFD50
;Type SP 0x1FD
ORG $03D4F5
DB $04, $FF
ORG $03D56B
DB $09, $FF
;New 0x1FD pointer 1
ORG $03FF04
JSL $BFFD45
RTS
;New 0x1FD pointer 2
ORG $03FF09
JSL $BFFD45
RTS
;This code here is compatible with all 3 codes
;New Kamek code
ORG $BFFCE4
TXA
STA $701FFF
LDA $70E2,X
SEP #$20
RTL
ORG $BFFD45 //This is the code of Sprite 0x1FD
LDA #$0001
STA $701FF4
RTL
ORG $BFFD50
PHA
LDA $701FF4
CMP #$0000
BEQ NORMAL
CMP #$0001
BEQ OFFSET
PLA
DONE:
RTL
NORMAL:
PLA
CLC
ADC #$0010
BRA DONE
OFFSET:
PLA
CLC
ADC #$FFD8
LDA #$0000 ///Edited Those two operations set $701FF4 back to zero, which actually should
STA $701FF4 ///Edited make Kamek turn back to normal, when Sprite 0x125's code is executed again
BRA DONE
|
| Last edited on 2012-01-24 07:49:53 AM by Yoshis Fan. |
|
| Posted on 2012-01-24 11:12:29 AM |
Link | Quote |
|
I can't tell what the problem is (I don't have enough ASM experience), but I'd assume you'd want to either set $701FF4 to #$0000 whenever the game loads a new Kamek sprite, or set $701FF4 to #$0000 when the game loads any new sublevel... is that what you're doing?
Also, if what matters is whether that RAM address is zero or non-zero, there's no need for the CMP #$0001 : BEQ OFFSET : PLA : RTL, since if it's not 0000, it won't branch, and you can assume it to be 0001 after that.
|
| Last edited on 2012-01-24 11:14:09 AM by Zeldara109. |
|
| Posted on 2012-01-24 12:42:32 PM |
Link | Quote |
|
@Zeldara:
Thanks for your input.
However, the ASM might be a bit misleading, but it edits the Kamek Sprite and adds Sprite 0x1FD
Sprite 0x1FD consists of the following code:
LDA #$0001
STA $701FF4
RTS
All the other things you see is the hijacked Kamek Sprite.
tehaxor69 has added the address check.
When Kamek's sprite is read by the game,
it does the check, wheter $701FF4 is #$0000 or #$0001.
If it is #$0000 it does ADC #$0010, if #$0001 it does ADC #$FFD8.
ADC #$0010 is used by the original Sprite, so if Sprite 0x1FD has not been executed (so $701FF4 is #$0000), it does not change the relation between Yoshi and Kamek. If $701FF4 is #$0001, the offset is applied.
So I thought: Right after the offset is applied, setting $701FF4 should actually normalize Kamek the next time the Sprite is loaded again.
Doesn't work, obviously, but I have no idea why...
*Edit*
Inserting this here
CodeORG $BFFCE4
LDA #$0000 ;;Actually way too
STA $701FF4 ;;simple to think of -.-
TXA
STA $701FFF
LDA $70E2,X
SEP #$20
RTL
and taking the other revert-$701FF4-back-to-zero-stuff out of the patch, it works perfectly.
So the Kamek patch thing is solved now (by myself, lol (Zeldara mentioned she wanted to do the same, but I didn't get it)).
|
| Last edited on 2012-01-25 05:32:10 AM by Yoshis Fan. |
|
| Posted on 2012-01-24 06:23:13 PM |
Link | Quote |
|
Originally posted by Yoshis FanCodeORG $BFFCE4
LDA #$0000 ;;Actually way too
STA $701FF4 ;;simple to think of -.-
That's actually what I was trying to suggest-- set $701FF4 to #$0000 when the game loads a new Kamek sprite, to cancel out the change made by the custom sprite. I guess the solution you found on your own happened to be the same thing? Well, what matters is that it's solved now.
By the way, what's the code you have now? I think I may be able to remove some unnecessary branching to save a few bytes, if that matters.
|
| Last edited on 2012-01-24 06:26:19 PM by Zeldara109. |
|
| Posted on 2012-01-25 05:29:55 AM |
Link | Quote |
|
Originally posted by Zeldara109That's actually what I was trying to suggest-- set $701FF4 to #$0000 when the game loads a new Kamek sprite, to cancel out the change made by the custom sprite. I guess the solution you found on your own happened to be the same thing? Well, what matters is that it's solved now.
Sorry, then, but I didn't understand how you meant that... 
I understood it as a question, so you'd ask me for the TIME when the patch reverts the value back to zero.
The byte reduction is actually not necessary I have had enough free space in the hack. Really not necessary, thank you for your offer anyways 
|
| Last edited on 2012-01-25 05:31:20 AM by Yoshis Fan. |
|
| Posted on 2012-01-31 02:51:08 PM |
Link | Quote |
|
@tehaxor69 and all others:
I've solved the issue with Piranha Plant in level 3-8.
I found a workaround for the issue, so no need to make any more research or look for solutions for that.
I've used another GFX set for Tileset 0xC:
The lower half is GFX set 0x09.
Problem is: They are used during the intro scene; see below...
Also, here is the modified graphic for 0xC for Tileset 0xB:
*Edit*
Damn, these bags are used during the intro cinema sequence. Isn't it possible to sorta alter the tilemaps or graphics to use?
The bag sprites start at 0x5D400 in the AllGFX.bin; I'd like to have them to 0x77400 instead.
Is there are way to do that, or is the graphic fixed to a kind of "bank"?
Actually, once the pointer(?) is found, it shouldn't be a problem to relocate it, since the sprites used in the intro cinema sequence are scattered around all of the AllGFX.bin file.
Please, if anyone capable of finding it/them reads this, have pity with me and help me with that.
|
| Last edited on 2012-01-31 03:47:10 PM by Yoshis Fan. |
|
| Posted on 2012-01-31 08:05:57 PM |
Link | Quote |
|
Here is the pointer for the bag that contains baby Luigi in the intro. This pointer is 3 bytes, and is the No Header ROM address + 0x400000.
SNES 0x06F979 ROM 0x037B79
[6A A5 57] = ROM 0x17A56A = SNES 0x2FA56A
Size 0x961
Compression codec LC_LZ2
I don't know how to change the ycompress offsets, you will need to talk to FuSoYa about that one.
|
|
| Posted on 2012-02-01 05:51:18 AM |
Link | Quote |
|
Thank you very much for finding that, tehaxor69!!
I've sent an E-Mail to FuSoYa and hope he will answer not that late (on his homepage, he says it can take 3 weeks to 3 years).
And in case he doesn't answer for whatever reason I will have to go for trial & error.
(Judging by the degree of compression of the graphics, which is ~2x, it should take me less than 53,248 tries to find the correct pointer by trial and error)
|
|
| Posted on 2012-02-01 06:02:53 AM |
Link | Quote |
|
|
For a slightly quicker response, perhaps you could try sending him a Private Message on here? His username is "Ayosuf". He's fairly active on this site and shouldn't take too long to reply.
|
|
| Posted on 2012-02-01 06:26:03 AM |
Link | Quote |
|
Thanks for the tip, Jeorge.
I really didn't know that he is registered here.
I hope he doesn't take it amiss, that I've sent a Mail and a PM.
|
|
| Posted on 2012-02-01 08:30:09 AM |
Link | Quote |
|
Originally posted by Jeorge535He's fairly active on this site
Yes, he's fairly quick to reply if someone says something interesting in the LM discussion thread - but he never logs in if he doesn't want to reply to something.
I'd guess he doesn't want to be in the online list more than neccessary. There's plenty of less intelligent users around here who could start harassing him if they find him.
Sadly, this also impacts his ability to respond to PMs.
|
|
|
|
|
|
|
Forum Index - Non-SMW Hacking - Yoshi's Island - YI hacking FAQ v2 (updated 2013-3-18) - Ask questions here! |
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To UsTotal queries: 27
|
|
|
|
