Acmlm's Board - I2 Archive - Super Mario World hacking - More Sprite Data [Info]
| User | Post |
cpubasic13
Posts: 671/1346 |
That is some nice data there. It helps a whole lot. Especially the sprite interaction area. I will probably experiment with this data some more and see what happens...
Good work, mikeyk. |
mikeyk
Posts: 18/110 |
With the recent interest in sprite data, I've decided to re-release the info that I gathered a few months ago. This file contains a bunch more info that I never posted before, specifically about the table at $1662 (0x3F535). Since the end of summer I really haven't had any free time to hack, but I'm glad to see some interest in sprite creation. Perhaps I can find some time to get back into it. Anyway, here's the data:
http://home.comcast.net/~dkaminski/smw_sprite.doc |
HyperLamer
Posts: 1828/8210 |
So the game just copies the tables to RAM and leaves them?  Seems pretty useless when it can just read them from ROM.
[edit] Alright, the sprite editor is starting to work. There seems to be a few bugs reading the data (I'm pretty sure Green Koopas are not visible on both subscreens), but for the most part it's good. Tomorrow I'll work on saving. I've also implemented a method that could be used to share custom sprites or make a database out of them. All it really does is display the sprite's hex code, it's only 10 bytes.  Working out the ASM data could be a bit of a problem but we don't even know how that works yet. 
Anyone know how the sprite data in RAM/ROM works? Like is there some way to use the 'extension' byte (grayed out in LM's Insert Manual dialog), or have sprite #s above 255? That would give a lot of room for custom sprites. At least does anyone know how the table in RAM works? If nothing else, an ASM hack could probably be developed to manually write extra sprite data into the table, but unless it has room for bigger 'Extra Info' data or a free byte, it doesn't help much. (That is unless you want to hack every reference to the sprite table to make each entry a few bytes bigger. ) Even then, I'm not sure how we'd go about adding these extra sprites in LM... Unless Fu wants to add support for them. 
But I suppose I should finish the editor and get cracking on figuring out the ASM before I try to figure that out. |
cpubasic13
Posts: 659/1346 |
Originally posted by HyperHacker
BTW, what I meant about the RAM tables was: say you wanted to change some attribute of a Green Koopa during the level. Would you write to index #4 on the table, or would that only modify the 4th sprite in the level? And when you went to another level, would the data still be changed or would it go back to normal?
That would modify the Green Koopa, not the fourth sprite in the level. I tested this when making a sprite similar to a shelless koopa and placed many in it and they work fine. Going from one level to the next is no problem either as that info stays intact throughout the game. |
HyperLamer
Posts: 1827/8210 |
Alright, I tried changing the bits, and this is what I found. All tests were done with sprite #4, the Green Koopa. Bit 7 is the highest bit, 0 is the lowest.
3F46C:
0: If 1, falls through first ground, walks 8px above second!
1: If 1, falls a few pixels through ground then bounces back up!
2: Same as 0.
3: If 1, animation is disabled.
4: If 1, it can be stomped. If 0, stomping it kills Mario/bounces Yoshi.
5: If 1, it dies when stomped, if 0, it acts like a Koopa.
6: Nothing?
7: If 1, when killed it disappears in a puff of smoke. If 0, it falls off the screen.
3F535:
0: Nothing?
1: If 1, its clipping range gets moved 16 pixels to the right.
2: If 1, its clipping range becomes 64 pixels wide.
3: If 1, its clipping range extends 16 pixels on both sides.
4: Nothing?
5: If 1, its clipping range moves up 16 pixles.
6: If 1, its clipping range extends 16 pixels on both sides, but the added area only affects Yoshi. (He gets scared off?
) Koopas have this set by default? (These might be a 'clipping range type' setting.)
7: If 1, it falls straight down when you stomp it.
3F5FE: Graphic-related. If the lowest bit is set it uses different GFX? The rest of the bits seem to either change the
palette or do nothing. Default is 0A.
3F6C7:
0: If 1, when you kill it with a star, it falls really fast, but you can hit it multiple times and bounce it in the air!
(It doesn't turn into a dead shell.)
1: If 1, it's invincible to stars, fireballs and the cape. (Hitting it with the cape still makes it jump though!)
2: If 1, it will still interact with sprites and objects no matter where it is in the level (even way off the screen)!
This slows the game down considerably, though. (Normally used for Yoshi.)
3: Nothing?
4: If 1, when you stomp it, kicking the shell only moves it a few pixels and gives you 200 points! Other Koopas will just
turn around when they hit it, so you can make barriers with it.
5: Nothing?
6: Nothing?
7: If 1, Mario can't interact with it, but Yoshi will still run away. You can still kill it with a cape or fireballs.
(Unfortunately, even if bit 1 is set, fireballs and capes still kill it.  )
3F790:
0: If 1, Yoshi can't eat it.
1: If 1, Yoshi holds it in his mouth. If 0, he swallows it and you get a coin.
2: If 1, if it falls from a high enough distance it will act as if the ground it lands on is about 3 pixels lower than it
really is.
3: If 1, it won't interact with shells. Even if you stomp it it won't get back in its shell.
4: Nothing?
5: Nothing?
6: If 1, it won't die when you stomp it, but you still get points! Stomping it with Yoshi or Spin-Jumping it will kill
it. (? blocks with green shells in them also wouldn't produce any shell!)
7: If 1, disables interaction with all objects (layer 1 or 2).
3F859:
0: Nothing?
1: Nothing?
2: Nothing?
3: Nothing?
4: Nothing?
5: If 0, the bottom half of the sprite is visible on both subscreens.
6: Nothing?
7: Nothing, but if bits 5 and 7 aren't both set, the death animation will show a koopa head instead of a shell.
87CC: Seems to be an ASM pointer. 2 bytes per sprite. Default is FC8A for Koopas. (Try 4D8C for bouncy koopas!)
9E7F: GFX-related table. Default is 00 for Koopas. 01 swaps the two halves, 02 makes the animations all goofy.
9D83: Animation-related table. Default is 84 for Koopas. 85 makes their heads mess up when they turn around. (Only seems to affect that frame?)
Now to start working on an editor. 
BTW, what I meant about the RAM tables was: say you wanted to change some attribute of a Green Koopa during the level. Would you write to index #4 on the table, or would that only modify the 4th sprite in the level? And when you went to another level, would the data still be changed or would it go back to normal? |
cpubasic13
Posts: 655/1346 |
To answer HH's questions:
So in RAM would they still be indexed by sprite #, or the order of the sprites in the level? And if you wrote to them would they go back to normal in the next level?
Well, that was from mike's notes, not mine. The sprites do work on more than one level. I have tested it and it did work.
So set bit 7 and it'll turn into a shell sprite when you stomp it? And what is falling/going "POOF!"?
No. Bit 7 deals with whether or not the sprite will jump into a shell (Koopas use this). And for when it falls, it is like hitting it with a cape, but it doesn't jump, but fall. And the POOF! thing makes it explode instead of fall or get squished.
I assume what you mean is bit 6 toggles whether the sprite is 8x8 or 8x16?
Yes and no. This makes the interaction area 8x16, but not the graphics look like that.
So the lowest bit toggles the palette page? Any idea what the rest do?
Not really, but I could figure it out. I would think, though, that this is all you need, as I tried using 17 instead of 07 and... well, I think it did the same thing as 07. I will have to check that again.
Is there a sprite that does this normally?
I don't think there were... unless I am mistaken...
So it acts like you killed it, but when it hits the ground it goes back to normal? Or does it just jump up?
It just jumps up. That is all.
What exactly does this do?
mikejk said it will decide whether or not it will fall through the ground. Bits 1 and 2 do nothing that I could see.
As in when you stomp it it becomes a bob-omb about to blow? What happens if this is set along with the bit that makes it go into a shell?
When you stomp on it, it will turn into a bob-omb about to explode. I have no clue what will happen when it goes in a shell... maybe a suicidal sprite... I will have to check into that...
Pic?
No need. Imagine the Koopa falling dead. That is all it does...
Same as...?
Same as the previous bit, but since I only use "same" when there is no effect, when you see same that means I don't know what it does.
Hope this helps... somewhat...
Smallhacker: Can't wait to see the editor. |
Smallhacker
Posts: 708/2273 |
Sure.
Anyway... I've started working on "Sprite-O-Matic", as I call it. So far, it can (exept for editing palettes) change if a sprite is stompable or not. That's at least something to start with. 
I'm planning on making a function called "Trade Code". Since only a few bytes per enemy is modified, this function will print the sprite's bytes. Then, you could give that code to another one, who inputs those bytes into Sprite-O-Matic and gets the same sprite as yourself. It could be really useful if someone makes a "Custom Sprites Archive"  |
blackhole89
Posts: 404/971 |
*is too lazy to start outlook right now* could you send it to me? I could even host it for you (~60% uptime only, but relatively fast).
~Blacky. |
Smallhacker
Posts: 706/2273 |
Originally posted by blackhole89
Check your loops. for(int i=0;i<8;++i) breaks before i=8. (duh)
Anyway, *wants*
Well, my program (which isn't made in C, by the way) isn't the problem. Not even hex editing works... There must be some kind of special "Palette 8" table somewhere in the ROM...
By the way... Since my host removed my account without any warning, there's nowhere to download it. I'd be happy if somebody could host it for me, but until then, email me (thesmallhacker@hotmail.com) and I'll send it to you. |
gnkkwinrrul
Posts: 359/647 |
Ah...no wonder my parabombs are still yellow and purple
go to the noob board. sprite paint is there |
blackhole89
Posts: 392/971 |
Check your loops. for(int i=0;i<8;++i) breaks before i=8. (duh)
Anyway, *wants* |
Smallhacker
Posts: 704/2273 |
Sprite Paint is a program I made that edits the palette of sprites. (Doesn't work on palette 8 enemies for some reason) |
blackhole89
Posts: 389/971 |
Originally posted by Smallhacker
Maybe I should rename and improve Sprite Paint by adding more editing options? Hmm...
What exactly is Sprite Paint?
(sounds like an editor I don't have yet to me... *wants*) |
gnkkwinrrul
Posts: 343/647 |
I think that would be a good idea |
Smallhacker
Posts: 701/2273 |
Maybe I should rename and improve Sprite Paint by adding more editing options? Hmm... |
HyperLamer
Posts: 1825/8210 |
The bits are ordered 76543210.
Originally posted by cpubasic13
0x03F46C -> 7E1656
0x03F535 -> 7E1662
0x03F5FE -> 7E166E
0x03F6C7 -> 7E167A
0x03F790 -> 7E1686
0x03F859 -> 7E190F
All of these tables are indexed by sprite number (starting with x00 for the shelless green koopa). Here's a few of my notes about some table values. I've still barely touched the surface of all this data. I have the RAM locations as the headers, cuz that's what I see in my trace logs.
So in RAM would they still be indexed by sprite #, or the order of the sprites in the level? And if you wrote to them would they go back to normal in the next level?
x03F46C
In the notes, he says it deals with whether it is stompable or not. Bit 1 (Not sure if it is bit 1... bits read as 00000001. Correct me if I am wrong) will determine whether or not it goes through the ground. Setting bit 2 makes it bounce very weirdly. Bit 3 does somewhat the same as bit 1. Bit 4 makes it slide on the ground. Bit 5 makes it stompable. Bit 6 does nothing? Bit 7 will determine whether or not to go in shells. Bit 8 determines whether or not it will die by "falling" or going "POOF!"
So set bit 7 and it'll turn into a shell sprite when you stomp it? And what is falling/going "POOF!"?
x03F535
Says for sprite interaction. Bits 1 to 5, I don't know what they do. Bit 6 makes the sprite have a "head" like a Rex. Bit 7... well, probably deals with the Koopas, but I am not sure. Bit 8 makes the sprite just fall when you jump on it.
I assume what you mean is bit 6 toggles whether the sprite is 8x8 or 8x16?
x03F5FE
Palette. If it is an even number (00, 02, 04, 06, 08, etc...) will set the palette to page 1, and the palette (Example: 00 would be sprite palette 0, page 1. 02 be page 1, palette 1. Get it?) Odd numbers make it page 2. Simple. Nothing complex.
So the lowest bit toggles the palette page? Any idea what the rest do?
x03F6C7
Hmmm... he wrote nothing on this... so... Bit 1 made the gravity for when dead really heavy.
Is there a sprite that does this normally?
Bit 2 made it invincible to the cape, but it still jumped in the air.
So it acts like you killed it, but when it hits the ground it goes back to normal? Or does it just jump up?
x03F790
Says walk through floor or sprite creating. Bit 1 does nothing. Bit 2 same.
What exactly does this do?
Bit 3 made it so when the sprite falls onto another ground, it walks 3 pixels in the ground (wha?).
Bit 4 makes it not interact with shells (maybe other sprites).
Probably for Mushrooms.
Bit 7 makes it an exploding Bomb-omb when you jump on it!
As in when you stomp it it becomes a bob-omb about to blow? What happens if this is set along with the bit that makes it go into a shell?
Bit 8 makes it fall through the floor.
Try setting this, putting it waaaaaay up in the air, and letting it fall. Does it just keep falling or does it stop eventually? Bowser's big ball things do this and don't have any layer 1/2 interaction (fall through the floor).
x03F859
Bit 6 made the death 16x32 pixels big.
Pic?
Bit 8 same.
Same as...?
x0087CC
Involves coding of the sprite. 2 bytes per sprite. I got it to freeze sometimes with some values, so now to experiment with sprite 12 (I made it a sprite like the shelless koopa for this part).
I set the code to 20 8A and it made a sprite stay still with no animation. Evil hidden guys? 20 8A made it do the same, but not interactable. So... now for the bits set.
Setting second byte's bit 1 makes game crash. Same with both bits 1 set. It will be hard to make this typed up so here is a little table.
Byte 1 bits | Byte 2 bits | Effect |
-----------------------------------------
00000000 | 00000001 | Crashed |
00000001 | 00000001 | Crashed |
00000002 | 00000001 | Crashed |
-----------------------------------------
I gave up since a lot of the stuff crashes the game. I did, however, make an interesting sprite. It will slide to the right at a fast speed. Set the bytes to 33 8A to have this sprite. That is an awesome sprite in my opinion. Wait... set the first byte to 4D and second byte to 8C and you got a jumping sprite. I did notice that the second byte is usually 8X (X is a number). Mess around with this, somebody, and figure it out.
Sounds like a series of 16-bit pointers to ASM. Dunno why that bit would make it crash (unless you were just pointing it to invalid code), or did you mean the highest bit? I don't think addresses xx8000-xxFFFF are valid.
The last thing is the graphics section at offset x009e7f and x009d83. The first edits the graphic tiles that the sprite uses. The second... I don't know what it does.
What's the format for the first table? Second might be animation or something.
Now someone make an editor as I am tired of using a hex editor.
A project for tomorrow. |
gnkkwinrrul
Posts: 332/647 |
No, it must have been byte 2. because it jumps in the air when I hit it with the cape. Also, I can't hit it with fire power or star power. |
cpubasic13
Posts: 653/1346 |
Then again, there were a few things I did not know about in the sprite interaction area. You probably did change those bits and that happened. Notice this...
x03F6C7
Hmmm... he wrote nothing on this... so... Bit 1 made the gravity for when dead really heavy. Bit 2 made it invincible to the cape, but it still jumped in the air. Bit 3 I don't know. Bit 4 is unknown. Bit 5 same. 6 same. 7 same. Bit 8 makes the sprite untouchable by Mario unless you use the cape (Set Bit 2 and 8 for NPCs for a village!!!).
Notice bit 8 and what it does... that means you changed this byte. Mess around with it... |
gnkkwinrrul
Posts: 327/647 |
Yeah, but it is a regular green koopa, remember?
I'd like to submit a squashable goomba |
cpubasic13
Posts: 652/1346 |
Bad idea. You know how many people would submit different types of stompable goombas? Lots. Plus not only that, it deals with the graphic locations which would have to be described where exactly they are stored.
Even with the hex code thing, it would be difficult for people to understand what they are doing. Maybe they want to alter the sprite, but they can't because they don't know what does what. That is why I would like people to use some editor that actually describes what you have to do so maybe we could have some interesting sprites. |
| This is a long thread. Click here to view it. |
|
labmaster
