 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| User | Post |
| Disruptive Idiot Posts: 21/56 |
Originally posted by BioOriginally posted by HyperMackerel But in the first level you collect the brick blocks that turn into coins when you hit the P-Switch. If a brick block had something in it, it looked like a coin with the P-Switch active, but it still acted normally. |
| C:/xkas bio.asm Posts: 575/1209 |
Originally posted by HyperMackerel nope, It seem to use an animation in smb3 too, the same one used to change coin into brick and stop ? block from moving  |
| HyperHacker Posts: 1652/5072 |
IIRC, they actually turn into coins in SMB3, not just look like them. |
| SnifflySquirrel Posts: 11/80 |
Originally posted by BMF54123 Actually, they remind me of the "turn blocks" from SML2, since they break when you spin jump them too. Originally posted by BMF54123 Originally posted by Stifu I think he means making the turn blocks act like coins when a blue P-Switch is active (since you could just use a custom animation to make it look like one ). If you do choose to look into this, I suggest creating a separate hack to make those brown "used" blocks NOT turn into coins when you hit a blue P-Switch. (Turn blocks becoming coins + used blocks becoming coins = too many coins  ) |
| Stifu Posts: 231/647 |
Originally posted by BMF54123 I don't remember very well, but if it's coins you can't collect (that is to say they're still bricks, only don't look like bricks anymore), then you shouldn't bother. It's better as is. |
| BMF54123 Posts: 276/876 |
Originally posted by MathOnNapkinsOf course...that's how the bricks behaved in SMB3. They only check Mario's size (LDA $19 in brick2) when he either spin jumps on them or hits them from below. 
Originally posted by MathOnNapkinsThat, unfortunately, I can't fix, since sprites and backgrounds can't share palettes. 
I nearly forgot that the bricks in SMB3 turn into coins when a P-Switch is hit...I wonder how hard it would be to replicate that behavior? Should I even bother doing it? |
| Deleted User Posts: 334/-7750 |
I have tryed it, it worked, but not fine. Letīs see, I have followed all your instructions, but it applyes to all the blocks, and Small Mario and Big Mario canīt break them  . |
| FPI Posts: 68/197 |
I could be wrong, but if I remember right, the same thing happens in the original SMB3/Allstars, by hitting a P-Switch, too. |
| Keitaro Posts: 260/373 |
One question. I just recently found a very nast glitch in the original FuSoYa (or whoever mde the smb3 blocks in demo world) SMB3 blocks, which when a P-Switch is activated, an smb3 block that contains a coin or an item will still act like that SMB3 block only with coin graphics when you hit a P-Switch I'm assuming that...dosn't happen here? |
| MathOnNapkins Posts: 375/1106 |
Well meh... I got bored and whipped up a patch that is equivalent. The labels I use are pretty generic and xkas could use a .label labels but I'm not sure if those are features of other assemblers so I just jused label: labels. Let me know if I transcribed something incorrectly.
edit: whooops  . Don't try to use org $1F0000... use $1F8000 or something. Either way I just patched and it seems to work. I also noticed that using shells and such will destroy turn blocks whether you are super mario or just mario.
Also, it's annoying that the palette still changes when they are bumped. At first I thought the patch didn't work. Then I realized it was the palette swap that was playing tricks on my eyes. |
| BMF54123 Posts: 267/876 |
Originally posted by MathOnNapkinsYes, that's how the original game does it. Specifically, the sprite it creates replaces the Map16 three times: when it bounces upward, it swaps in a solid placeholder (probably to prevent sprites from falling through in the brief moment the block is bouncing), and when it drops, it swaps in the "always-turning turn block" for #$FF frames (the value at $10A76). Once the counter reaches zero, the sprite swaps in the original turn block, and then deletes itself. Each sprite takes up one entry in the sprite table, and is processed even while offscreen, which is why you can only have 4 active blocks at any given time. With my new routines, if small Mario hits a block, the original "bounced block" routine is called; if big Mario or a sprite hits the block, the "broken block" routine is called. The latter requires specific values to be present in A and Y, and also requires Mario's Y speed to be preserved (otherwise he bounces upward whenever a block breaks, likely part of the spin jump routine). This is why simply replacing the original JSLs wouldn't work. Originally posted by MathOnNapkinsI would've just made an IPS patch, but I have no idea what space is available in any given ROM, since Lunar Magic and Block Tool both scan for empty space and use whatever they can find. I didn't want my new routines inadvertently overwriting any existing data. |
| Skreename Posts: 161/1427 |
The ones in blocktool don't seem to behave quite right, from what I've seen. The original blocks will jump up, leaving a blank space where they were in the meantime, while the ones in blocktool from what I've seen merely spawn the sprite, leaving the original block in place during the process, which looks... sloppy. |
| spel werdz rite Posts: 977/1796 |
I removed the "bump" routine in BlockTool. I didn't like it. |
| FPI Posts: 62/197 |
Originally posted by Bio Yes, I'm sure they have it already.  |
| C:/xkas bio.asm Posts: 545/1209 |
aren't the one in blktool(not the one in DW and DW:TLC one) already have the bounce block effect? |
| MathOnNapkins Posts: 359/1106 |
So am I correct in saying that when you bump these blocks, the original map16 block is erased and you create a sprite instance? That seems to be the approach I'd take. Also what's with the .bin files, wouldn't it be easier to provide an asm patch? I'd convert if for you if you want. |
| BMF54123 Posts: 265/876 |
Yes, I realize that SMB3-style bricks have been available for some time now...however, they're not quite "right" (the blocks don't bump up when small Mario hits them, for example). I've decided to remedy this the only way I know how: by spending a whole night figuring out sprite-block interactions, and making my own routines from scratch! 
First off, find some free space in your ROM, and insert the following two routines: brick1.bin brick2.bin Convert the starting address of both routines to SNES format and write them down. Next, go to the following addresses, and change each JSL to point to the new brick routines: $97D2: brick1 $9BC9: brick1 $1182C: brick1 $6F02: brick2 Finally, change $10A76 to 06; this will prevent the bricks from turning when small Mario hits them (or you can leave this at FF and have "hybrid" turn-bricks). That's all there is to it! The original turn blocks should now behave exactly like SMB3 bricks. Hitting them as big Mario, kicking a sprite into them, smacking them with your cape, and spin-jumping on them will cause them to break, while hitting them as small Mario will merely bump them up (knocking out any enemy on top, of course).
If you run into any odd behavior or crashes, please let me know exactly what you did to cause it. I'm pretty sure I tracked down all the necessary turn block routines, though I may have missed one or two. |
