 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Super Mario World hacking:  labmaster |
| Acmlm's Board - I2 Archive - Super Mario World hacking - More Sprite Data [Info] |
 |  |  |
| Pages: 1 2 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
|
cpubasic13 17 years old now. Time to buy some M rated games by myself! Level: 54  Posts: 655/1346 EXP: 1206934 For next: 26936 Since: 03-15-04 From: Blame my parents, Eddy Since last post: 2 days Last activity: 1 day |
| ||
| 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. |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 1827/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| 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 17 years old now. Time to buy some M rated games by myself! Level: 54 Posts: 659/1346 EXP: 1206934 For next: 26936 Since: 03-15-04 From: Blame my parents, Eddy Since last post: 2 days Last activity: 1 day |
| ||
Originally posted by HyperHacker 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 <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 1828/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| 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. (edited by HyperHacker on 10-21-04 01:25 AM) |
|||
mikeyk Koopa Level: 18 Posts: 18/110 EXP: 25086 For next: 4811 Since: 07-17-04 Since last post: 45 days Last activity: 44 days |
| ||
| 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 |
|||
|
cpubasic13 17 years old now. Time to buy some M rated games by myself! Level: 54 Posts: 671/1346 EXP: 1206934 For next: 26936 Since: 03-15-04 From: Blame my parents, Eddy Since last post: 2 days Last activity: 1 day |
| ||
| 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. |
| Pages: 1 2 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Super Mario World hacking - More Sprite Data [Info] |
| | |
