Posts by Romi - SMW Central

(restricted)

Long post, sorry.

xkas patch

Using this .asm file, you can select which room (well, I just prefer calling it room in YI) uses Brown Chomp Rock.

I say, rooms are diffrent from levels. Levelas are, 1-1, 1-2, 1-3 and so on, like Golden Yoshi mentioned.
Rooms are,

00 1-1 Main
01 1-2 Main
02 1-3 Main
...
...
3A 1-1 Bonus Room
...
DD Baby Bowser

You can know what value is for what room, from the dialog of Egg Vine. ( Level -> "Load Level by Index" )

In the .asm file, a long table contains many 0's is there. You can specify 0 or 1 for each bit.
The room list whose values are 00-DD is corresponding to the actual table above. Refer to the room list to know which bit is for which room. A bit being 1 means a Brown Chomp Rock appears in that room. If it's 0, it won't.

e.g.

As you can see, a red bit and a yellow bit are set to 1.
This means, in the room-00 and the room-3A, a Brown Chomp Rock appears.

You can patch the .asm file as many times as you want. So, after you modify the table values, you can repatch it.
But don't forget to make a back-up.

[EDIT] Oops, forgot to mention.
I used SRAM $70:1FFE and $70:1FFF for storeing an actual room number so that the game can load the number during game-play. But I'm not sure if the RAM is free at all. If something is screwed up, you can change the RAM to another address.

Code

.table			db #%10000000	; 00
			db #%00000000	; 08
			db #%00000000	; 10
			db #%00000000	; 18
			db #%00000000	; 20
			db #%00000000	; 28
			db #%00000000	; 30
			db #%00100000	; 38
			db #%00000000	; 40
			db #%00000000	; 48
			db #%00000000	; 50
			db #%00000000	; 58
			db #%00000000	; 60
			db #%00000000	; 68
			db #%00000000	; 70
			db #%00000000	; 78
			db #%00000000	; 80
			db #%00000000	; 88
			db #%00000000	; 90
			db #%00000000	; 98
			db #%00000000	; A0
			db #%00000000	; A8
			db #%00000000	; B0
			db #%00000000	; B8
			db #%00000000	; C0
			db #%00000000	; C8
			db #%00000000	; D0
			db #%00000000	; D8

; Room List
;		db (00)(01)(02)(03)(04)(05)(06)(07)	; 00
;		db (08)(09)(0A)(0B)(0C)(0D)(0E)(0F)	; 08
;		db (10)(11)(12)(13)(14)(15)(16)(17)	; 10
;		db (18)(19)(1A)(1B)(1C)(1D)(1E)(1F)	; 18
;		db (20)(21)(22)(23)(24)(25)(26)(27)	; 20
;		db (28)(29)(2A)(2B)(2C)(2D)(2E)(2F)	; 28
;		db (30)(31)(32)(33)(34)(35)(36)(37)	; 30
;		db (38)(39)(3A)(3B)(3C)(3D)(3E)(3F)	; 38
;		db (40)(41)(42)(43)(44)(45)(46)(47)	; 40
;		db (48)(49)(4A)(4B)(4C)(4D)(4E)(4F)	; 48
;		db (50)(51)(52)(53)(54)(55)(56)(57)	; 50
;		db (58)(59)(5A)(5B)(5C)(5D)(5E)(5F)	; 58
;		db (60)(61)(62)(63)(64)(65)(66)(67)	; 60
;		db (68)(69)(6A)(6B)(6C)(6D)(6E)(6F)	; 68
;		db (70)(71)(72)(73)(74)(75)(76)(77)	; 70
;		db (78)(79)(7A)(7B)(7C)(7D)(7E)(7F)	; 78
;		db (80)(81)(82)(83)(84)(85)(86)(87)	; 80
;		db (88)(89)(8A)(8B)(8C)(8D)(8E)(8F)	; 88
;		db (90)(91)(92)(93)(94)(95)(96)(97)	; 90
;		db (98)(99)(9A)(9B)(9C)(9D)(9E)(9F)	; 98
;		db (A0)(A1)(A2)(A3)(A4)(A5)(A6)(A7)	; A0
;		db (A8)(A9)(AA)(AB)(AC)(AD)(AE)(AF)	; A8
;		db (B0)(B1)(B2)(B3)(B4)(B5)(B6)(B7)	; B0
;		db (B8)(B9)(BA)(BB)(BC)(BD)(BE)(BF)	; B8
;		db (C0)(C1)(C2)(C3)(C4)(C5)(C6)(C7)	; C0
;		db (C8)(C9)(CA)(CB)(CC)(CD)(CE)(CF)	; C8
;		db (D0)(D1)(D2)(D3)(D4)(D5)(D6)(D7)	; D0
;		db (D8)(D9)(DA)(DB)(DC)(DD)(**)(**)	; D8
; ** is unused

Originally posted by GOTHCLAWZ

I was going to mention that, but does the Super Mario World engine support upto 5 players?

This is a small test of multitap for SMW. (just a test, not a complete patch or anything else.)

I tested with snes9x 1.51.
To activate multitap on the emulator, push '7' key 3 times. I think this will be displayed :
Port 1: Pad #1. Port 2: Pad #2. Pad #3. Pad #4. Pad #5.
And enable Pad 3 and play the game.

This worked at least for me, so I guess it's possible to make SMW support multitap?
But if you really want to use Pad 3 for your game, adjusting all player-related RAM addresses, such as lives, coins, and so on, would be a bit hard.

Originally posted by BulletBillTime

-Is there a way to disable the intro level, and simply lead to the map instead?

Change 1 byte at 0x263AE [0B] to [1F], and 1 byte at 0x263B4 [0B] to [00].

I hope anything, like initialization for the game, isn't done between opening scene and intro screen's appearance.

(restricted)

I don't remember this has been already posted, though, I'm going to post anyway.

Changing 1 byte at 0x80F9C to 00 disables that Yoshi faces to left when level starts, in 1-5, 2-7, and 5-7.

Thank you.

But, looking into something only when someone asked question, I really even don't know irrelevant information.

I don't think this would be useful to people, but I started to make a RAM Map of YI.
But it's not at all filled currently.

And, I thank Mattrizzle for posting some information of RAM as well as ROM offsets.

Well, I asked one moderator if I could bump the thread, and told me ok.

This update is at least more important than just supporting xkas.
You may have read these thread.
http://www.smwcentral.net/?p=thread&id=8605
http://www.smwcentral.net/?p=thread&id=10522

I think I fixed this problem, without modifying .cfg of the torpedo sprite.
When mikeyk released v1.35, he added the feature to let you controll your sprites more flexibly.

Originally posted by mikeyk at board 2

The 2 most significant bits of "Extra Property Byte 2" are now used to control how custom Sprites are handled when the status isn't 1 or 8:
* If neither bit is set, MAIN is called after the default handling of statuses 3,9,A,B. This is pretty much how Sprite Tool works now, except I added status 3 (smushed) to the list. This was designed so sprites can use the default handling routines, but use different graphics in the end.
* If bit 6 (0x40) is set, MAIN is called after the default handling of all statuses.
* If bit 7 (0x80) is set, the default handling is not used at all. MAIN is responsible for handling all statuses.

This should just give a new possibility for a sprite, though, there was an issue.

As you may know, whether or not a sprite is custom depends on $7FAB10,x's bit 3 (08), and in order not to make normal SMW sprites placed in level custom, $7FAB10,x is always cleared when $14C8,x==0, while $7FAB34,x is just left.
And Extra Property Bytes are only initialized in INIT routine, so the next sprite will inherit the value until the next sprite initializes them.

I'm not sure if mikeyk expected this, though, "all statuses" maybe unexpectedly included INIT status. So, if a sprite's ExPropByte2 had bit7, the sprite even have to handle INIT routine in MAIN routine by himself even though sprite has INIT routine separately from MAIN.
Of course, all sprites were not made so they call INIT in MAIN, the affected sprite couldn't call INIT. This is why sprites randomly glitched.

So, I updated the main code to fix this problem. And now, you don't need to put main.bin and main.off in your folder. The main code will be automatically inserted.
~~download~~ Older version removed

Besides this, I made some adjustments for sprite tool and cfg editor to fix a few minor things.

And you don't always have to run the tool from a batch file or command line. I remade it like mikeyk was originally doing.

@MetaKnight
Thanks! But if a sprite doesn't need to be carryable-status and such, we should set the sprite's Extra Property Byte to lower than 0x40 or 0x80.
Though the torpedo problem was solved, I recommend you all who are using smkdan's torpedo sprite setting its Extra Property Byte 2 to 00, as people who posted in the mentioned threads did.

@Ersanio
Yeah, I think it should.

@FPI

After running some tests and debugging for a while, I noticed that the inheritance of a timer ($15AC,x) caused this problem. Though a sprite's other timers are always initialized when the sprite appears, the timer $15AC,x seemed not to be initialized even in original SMW code. So, I guess this problem was SMW's problem rather than custom sprites or Sprite Tool itself.

And SMW's basic sprites are using this timer for flipping their direction. So, if the sprite accidentally inherited the longer timer from sprites that existed, they would behave a bit weirdly.

I tweaked the main code to fix this, too.
I hope this will work.

~~Sprite Tool v1.38~~

@andy_k_250

Thank you for pointing that out. Tried with a carryable sprite, and also it crashed the game...
I remember that carryble sprites worked fine with 1.37 (or 1.36), so apparently I made a mistake when updated the tool to 1.37 to 1.38 (or 1.36 to 1.37)
I really should have tested much... I apologize to you for having made you annoyed with this problem.

Download link is in the first post

In case you don't notice, I updated the cfg editor as well.
Now all bits' description were labeled, and you can view "Sprite Clipping" with this tool after loading your ROM.

@MrDeePay

Ah. I'm terribly sorry...
I had been completely forgetting about a poison mushroom.

I updated the tool to 1.39.1
The download link is the same as 1.39

0x64D0 2bytes [6D 00] (109 in decimal)
Until the star count reaches this value, it recovers automatically.

0x64E9 2bytes [64 00] (100 in decimal)
When the star count matches this value while recovering, the game plays a sound effect.

0xB1DD 2bytes [64 00] (100 in decimal)
The initial star count.

0xC4BD 2bytes [6D 00] (109 in decimal)
Until the star count reaches this value, the game always displays the current star count near the top of the display.

The current star count is stored in RAM $03B6 (2bytes, and watch it as decimal value, not hex), but it includes the first decimal place.
Divide it by 10 to calculate the count the game displays.

Originally posted by Fuzzyfreak

Sprite Status Table (7E14C8 - 7E14D3)
07 - Unused

It's not actually unused state. It's the state while a sprite that won't be swallowed immediately is staying in Yoshi's mouth.

@Buu-Huu

Aren't you enabling animation of Lunar Magic?
I could edit the palette 64 if I disable it.

Code

LDA #$06
STA $1F11 ; Map number

REP #$20
LDA #$01D8
STA $1F17 ; X position
LSR A
LSR A
LSR A
LSR A
STA $1F1F

LDA #$01D8
STA $1F19 ; Y position
LSR A
LSR A
LSR A
LSR A
STA $1F21
SEP #$20
RTS

Please try this code.
I hope this works.

@S.N.N.
Nice work. The sound effects list may help people when YI hacking will be more advanced.

0x7B689 [01 00 FF 00] 2 bytes each, (00 01) : counterclockwise, and (00 FF) clockwise
The distance Raphal The Raven moves.

This expression may be inappropriate, but for the sake of convenience, I'll express it as "speed"

The small moon's circumference is 0x100, so when the speed is 1, Raven makes a round of the moon in 256-frame.
These are rates of speed in each time.
1st (HP3) : x 1.0
2nd (HP2) : x 1.25
3rd (HP1) : x 1.5

But, even changing the speed to 2 makes him a bit too fast.
If you want to set him speed like most of the sprites, not as the distance, you need to hack the routine a bit.

@S.N.N.
Sorry, I don't know much information about even existing sprites yet. Some information about Raphael The Raven I posted is what I just luckily found.
And, nice work on the music again.

Also, a few more information about him I found near the offset I posted in my previous post.

0x7B308 [07] : Raphael The Raven's HP
This is specified in binary. 0x07 -> 00000111
If you want to increase his HP, just increase the number of a bit being 1.
For example, specifying 0x1F (00011111) will make him have HP5. The max is 0xFF (11111111), HP8.
If you change this byte, also change the byte at
0x7B70D [07] to the same value

0x7B8A1 [06 08 09 09 09 09 09 09] : The image of Raphal The Raven
Each byte is corresponding to the times he got hurt.
Here's a list of it.

00 - Whitish body
01 - The same color as the sky
02 - Same as above, but with a star
03 - Wrong palette
04 - Wrong palette
05 - Same as 02, but with blue light outline
06 - Normal
07 - Yellow body ( when getting hurt )
08 - Angry
09 - Furious
0A or higher - Wrong palette

The first byte of the table is 06, but this doesn't seem to be used. Instead, change the byte at
0x7B682 [06] : The initial image.

Sorry for the bump again.
But please let me tell you two things.

1.
I'm sorry it's too late to tell, but again the tool is updated.
All known issues, so far, are fixed now.

2.
I'm given permission to distribute all sprites made by mikeyk which are included in the Sprite Tool 1.35
Thank you very much to mikeyk for this!

Please redownload the tool if you are using 1.39.1 or older, thanks.

EDIT: Download link is in the first post

1. Best regular member - andy_k_250, Golden Yoshi
2. Best local moderator Ersanio
3. Best full moderator Kyoseron
4. Best administrator S.N.N., Boom.dk
6. Best graphics artist icegoom
11. Most creative Kc, Golden Yoshi
22. Most likely to drive a mack truck into a building out of boredom Ersanio
26. Best holiday name change candy_kane_250
33. Funniest Smallhacker
34. Smartest smkdan
39. Most missed icegoom, mikeyk