Name: | GreenHammerBro's SMB3 screen scrolling pipes 3.2.14 |
Author: | HammerBrother |
Added: | |
Version History: | View |
Act As: | 130 |
Includes GFX: | Yes |
Description: | FuSoYa's pipes patch wasn't compatible with Gopher Popcorn Stew, so I uploaded my own. These pipes, when entered, will cause mario to travel through pipes within the same level rather than refreshing the screen, useful for maze levels for those who refuses to use screen exits (which is a pain). Whats best is that: -unlike wiiqwertyuiop's, this centers the player correctly and is impossible to make the pipes play a "pipe sfx" multiple times for entering/exitng the pipe. -there are several (more like countless) bugs in mikeyK's pipes (outdated) ranging from passable corners, to horizontal pipe caps that you can enter randomly not working should there be a level time limit, all the way to ceiling slopes teleporting mario (or killing him based on y position). -now there are pipe turn-corners for mini pipes!! -the best thing ever about this is that GPS has a "block to insert" list, due to having multiple blocks in this package, It made it easier for inserting all the block at once just by copying whats in "pipe_tiles_list.asm" and pasting it in "list.txt". THANK GOD that was faster than tedious editing whats in "edit block database" of btsd and that btsd insert the blocks one by one at a time. I couldn't fit the description in the print command (they are often long; they would overwrite descriptions of other blocks), but I made a .map16 so its easier to understand. see the readme for details. Notes: -If there are at least 2 sprites on screen, and mairo enters a pipe, mario will partially disappear as he enters a pipe, you should download the "no more sprite tiles limit" to prevent that. -If you have a low-gravity generator that DEC $7E:007D (mario's Y speed), make sure that you add a check that if $7E:009D or a ram address for "!pipe_dir" is a non-zero, then skip/return, because mario will then rise up slowly while traveling through horizontal pipes. -If you have converted ram address (and modify the GPS tool) to be compatable with sa-1, you also have to convert the "sprite slot loop" to use 22 slots. Because SA-1 has updated the number of slots from 12 to 22, otherwise yoshi glitches up. You can now use these pipes in layer 3 tides. |
Tags: | lorom maze pipes sa-1 |
Comments: | 70 (jump to comments) |
Rating: |
Download
512.50 KiB | 1,787 downloads
Comments (70)
Sounds like you didn't remove test.asm from the list for level 105 in the uberasm list.
-Turn block bridge that expand vertically (sprite 59) had a faulty restore code:
Sprite_TurnBlockHV_pos: ;>JML from $01B882 LDA !Freeram_SSP_PipeDir AND.b #%00001111 BEQ .Restore JML $01B8B1 .Restore LDA $0D CLC ADC #$1F JML $01B8B1
Change the red number to $01B887 to fix the issue.
I have been frustrated with these pipes for quite a few months, and I cannot stress the following rule of thumb any further: make sure to edit both copies of the defines file in the correct directories, such as the 'blocks' folder in GPS and the same directory your UberASMTool is in. If you have have a copy of the 'SPP_Defines' folder outside those important directories and you replace the defines file there, then surely you're missing something!
And a high recommendation: use this patch to free up a whopping 16 KB of arbitrary freespace, starting from $7F0000 to $7F3FFF. This freespace will thus be safe to use in the long run. Wish you the best of luck! Your frustration with these pipes should now be put to an end!
Same.Someone needs to make it compatible with Reverse Gravity.
I didn't used the uberasm version, I used patch version.
Edit: Never mind, it works now
Fusoya's pipes truly are cursed.
Try to apply Fixes.asm
Just replace this
with this
Ooh, seems that the check:
What type of bug are you getting. Did the game first reload the level, and then get locked there? Or did it get locked right when you enter the pipe?
For me this was an issue with the ExGFX settings. I believe BG3 needs to be set to 80, assuming you kept the GFX file name the same.
need to put them on page 5. otherwise it works great.
This could also fix the reset issue which could happen when you die in a pipe and use $7Fxxxx as freeram, even if you don't use retry.
Yeah, I've should noted that on the readme about that. It is very likely to see this flicker for sprites larger than 16x16 (for example: the giant koopa), especially for small screen scrolling pipes. The reason for this is that only the player becomes invisible after the entering animation timer hits zero, the carried sprite remains visible and therefore can “poke” outside the pipe.
And also, thank you for testing and reporting.
I also forgot to write that vertical pipes acts a bit weird if they haven't got a middle part. See the second to last obstacle in the demo level.
For the fireball part, I believed the error is caused by this on the uberasm library code (so far, mario actually shoots fireballs while inside the pipe, it maybe a frame-perfect timing to exit the pipe while no fireballs are present on the two slots):
Noticed that this sets and clears both $15 and $16. $16 is used for the cape and fireball action. This glitch even happens on cape (it only plays the SFX).
I really don't know how yoshi becomes invisible when setting $78, but when yoshi crouches and faces the screen when entering screen scrolling pipes when you set the value on $7E1419, he still does that even if the player is not mounted on him. This works even on the original game with its exit-enabled pipes. That RAM is used because that also controls how you carry sprites through pipes.
The new addition with the controllable turn corners makes designing the pipes more interesting. It also is a bit similar to FuSoYa's two-way pipes except more flexible and maybe even easier to understand.
The only problem is that Fire Mario drops a fireballs when exiting a pipe (and it even fries any sprite because Mario is considered in the pipe state). The invisible Yoshi glitch also is something to consider (it wouldn't have been as bad if cape and Yoshi weren't aren't affected by the same invisible bit). Maybe adding an option to turn Mario temporarily small à la FuSoYa to fix this problem?
The option to prevent Yoshi entering the pipe also would be nice.
The Fixes patch fix it lol
The horizontal tubes do not work
While I couldn't find any major problems that were severe enough to justify rejection of this submission, I did at least find two minor problems that should be taken a look at whenever considering an update for the pipes.
For the first problem: When entering horizontal pipes, Mario never seemed to play his proper "walking into pipe" animation, unless currently riding Yoshi. He just slides into the pipes. Certainly not a big deal, but for more authenticity, you should consider adding this animation in a future update.
For the second problem: The code is a bit unoptimized in a few places. For example, I found code like this in multiple locations:
Consider rewriting the code like this to save cycles and bytes:
That being said, none of these problems affects functionality or is a game breaker in my books, that's why I went ahead and accepted the submission, anyways.
I observed that the program bank was not equal to the data bank in routines/SmallBlockHitbox.asm, and the blocks changing the directions didn't work properly. You may want to use LDA.l to access the table (maybe in some other block codes too).
When mario enters or exits from a pipe, sprites(especially ones consisting of multiple tiles) won't be drawn correctly, even with the NMSTL patch. This can be resolved by setting the value of $13F9 to #$02, instead of #$01.
It will let Mario to enter the pipe, and glitch like below.
I didn't come up with the best solution, but for right now, just add code so pipes will not let Mario in when he has upward speed.
like..
LDA $7D
BMI return
I think I found a bug maybe?
I used one of the old versions so I am not sure.
However, this is fatal, because it causes game crash. (not glitchy but pauses forever)
Could you verify this and possibly fix it please?
I'm not gonna use THIS 'cuz you konw. No sa-1 tag, thus no SA-1 usability.
I found another glitch in your scrolling pipes code, and thought you might want to know. The issue occurs when you try to enter a horizontal pipe while standing on any downward-moving sprite platforms. You can enter them if you press jump at the perfect time, but this is rather counter-intuitive and goes against how the vanilla pipes behave.
Thanks again for the cool patch/blocks.
Don't place sprite platform near pipes.
Everything else seems unedited and inserted just fine.
I did not modify that file at all, so I'm just wondering what could be the problem here. (For extra info, this only started happening when I remembered to set the freespace in the uberASM file and the pipe_defs.txt file.)
It should work, if you select freeram that isn't used by other stuff, you should be fine.
@[everyone]
It doesn't need exit tiles in front of the pipe caps, as the caps themselves do the exit timer, that means you can put any tile in front and it won't glitch your pipes.
I'm not sure, I tested this on a edited level rom (so LM adds stuff to it).
Also, does this require an unedited ROM to do this?
Fixed typo.