| Name: | SMB3 Screen Scrolling Pipes 4.0.2 |
| Author: | HammerBrother |
| Added: | |
| Version History: | View |
| Act As: | 130 |
| Includes GFX: | Yes |
| Description: | See tutorial here. The blocks section has a small 1MIB limit preventing me from submitting this as a whole. FuSoYa's pipes patch wasn't compatible with Gopher Popcorn Stew, so I uploaded my own. Even if it's updated to work with GPS, it is buggy. 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 blocks at once just by copying what's 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. 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 is nonzero, or the low nibble (low 4 bits, %----XXXX) of a ram address defined "!pipe_dir" is non-zero, then skip/return, because mario will then rise up slowly while traveling through horizontal pipes. You absolutely don't want to touch his physics while inside pipes. You can now use these pipes in layer 3 tides. Version 4.0.0 updates: -Added screen scrolling *warp* pipes -Cap cannons -Several bug fixes -Blocks rearranged -Vertical pipes (normal-size) enterable-width can now be customized v4.0.1: -Fixed a potential issue where setting $13FB (often set by yoshi growing animation) during pipe transition does not freeze the timer !Freeram_SSP_PipeTmr. Most likely this bug will happen with other ASM resources using $13FB See more in Version_History.txt. Github: https://github.com/GhbSmwc/SMB3_ScreenScrollingPipes |
| Tags: | lorom maze pipes sa-1 |
| Comments: | 113 (jump to comments) |
| Rating: |
Download
199.96 KiB | 1,681 downloads
Comments (113)
You can search on it in the file
I'm sure it's in the" fixes" file
In the line 74
.
For the first time it dosen't work
I serched a lot about the problem
then i found someone say to change "insrsce"../SSPdef/Define.asm" to "insrce"./SSPDef/Define.asm" or something like that
It mean to change `.." to `."
And it worked
You have to fix that problem becaus many users Don't know about that
..HidePlayerroutine where if you have a Yoshi active in the level, and you enter the pipe the Yoshi disappears. To fix it you can change the following lines (in the ScreenScrollingPipes.asm library file):into this:
Mario will not be able to come out of the earthen pipe and cannot be used together.
https://www.smwcentral.net/?p=section&a=details&id=18720
!pipe_dirneeds to be checked, not the address as a whole.- Lunar Magic 3.30
- GPS 1.4.21
- UberASMTool 1.4
- Asar 1.81
- SA-1 Pack 1.40 (also tested without)
- Snes9x v1.60, bsnes-plus v05
This version was just some minor bug fixes from the last version that was already approved. Accepted without issue.
In v4.0.0, I've noticed that there are a few instances where there's particularly bad sprite lag after patching the SSP fixes patch in combination with No More Sprite Tile Limits in particular (v1.2.1, the latest stable version).
I patched them to a clean rom — the only other modification being FastROM — and had heavy slowdown while there were 4+ sprites on-screen in two different scenarios: in an interactable layer 2 level I made, and at that long line of koopas at the beginning of vanilla level 106. (Both scenarios prominently involved shells, for what it's worth. Also, the lag in the layer 2 level was removed when changing it into a normal mode 00 level.)
I tested these scenarios with a number of other patch combinations, too. No More Sprite Tile Limits on its own had no effect here. NMSTL + frame rule patch produced negligible lag; and the SSP patch + frame rule patch had a bit more lag. But it was only the specific combo of the SSP patch with No More Sprite Tile Limits that can really produce severe lag here.
I know that using both patches just increases the amount of processing in general; but I figured I'd still bring it to your attention, on the chance that you can think of anything that might help the two patches co-exist a bit better in situations like these. (I also have some videos I made that show the exact setups with the lag, too, if you'd like to take a look.) Thanks a lot!
I did want to let you know about an issue with the fixes patch. So there is an extra NOP that appears in the hijack at $01A14D. One NOP overwrites the LDA portion of LDA $1A that is at $01A152 which causes glitches when stunning a mecha-koopa if said patch is applied. I just wanted to let you know about the issue!
Thanks for all of your hard work with these pipes!
On a super minor note: I'm using v2 of the blocks/tiles, and it looks like 4C0 and 4C1 — two of the DragPlayer.asm tiles — weren't assigned GFX, and appear as untextured tiles. You can simply copy over tiles 440 and 452 for them, respectively.
[Edit:] I'm deleting everything else I had written after this. Those blocks originally weren't working for me at all, but I didn't realize there was a level table in SSPDragMarioMode.asm; and I had saved the demonstration level to a level number other than 105. (The graphics issue was just a coincidence.)
Show me the error on the screen.
ok i applied fixes.asm as i thought i didn't need it and it worked thanks
i installed every thing correctly however for some reason only the vertical pipes work while the horizontal ones won't work at all
do you have any idea on why this is happening?
did you test this in a clean rom? Note that several RAM addresses are used, also, fixes.asm that came included is needed since blocks can’t properly check if the player is on the floor.
i installed every thing correctly however for some reason only the vertical pipes work while the horizontal ones won't work at all
do you have any idea on why this is happening?
Zeproide Did you insert the uberasm code via uberasm tool? That is the code that handles the pipe state of the player. That is the code meant to run every frame (runs the main if the pipe state is nonzero).
(the reason why the player goes through everything is because fixes.asm modifies a lot of the physics that may cause issues with the player's interaction with objects and sprites. In this case, it skips code that would eject the player out of blocks (such as moving him slowly to the left when clipped into it), this is to prevent possible minor bug where the player enters a bottom vertical small pipe cap being 1 pixel off)
Galeth There is a link to the documentation in the description.
You welcome! Just imagine maze levels with pipes not being physically connected, or to have passible pipe parts and platforming areas being in the same spot without blocking that area.
Looks like pixi does not support macro labels.
Lunar Magic 3.21
GPS 1.4.1
UberASMTool 1.4
Asar 1.71 + Walljump/Note Block Glitch Fix v1.6
Pixi 1.2.15 + Pinkie the Carriable Triangle
SA-1 Pack 1.32 (also tested without)
Snes9x 1.60
What a release! These pipes are quite useful and really easy to place within the level. After testing out all of the different features and trying different combinations of pipes, carriable sprites, yoshi, and powerups, everything seems to work as intended, with only two minor things to note. Regardless, this pack is accepted.
For whatever reason, if Yoshi is standing somewhere on screen and you enter a pipe (not riding Yoshi), Yoshi will disappear, even with the NMSTL patch. Both on lorom and SA-1. This is an incredibly minor bug and shouldn't be too difficult of a fix. Given how minor it is, this can still be accepted.
Upon moderation, the Pixi routine included didn't insert properly due to faulty label names, so I re-named them and updated the submission file. Quick fix, tested with the carriable triangle sprite.
I would say, just use the patch (fixes.asm) of this updated version, so far, doesn't have major issues.
This newer version features “2” versions of map16, an old one and a newer version. The newer version features way more blocks (takes up a total of 2 map16 pages), and are rearranged with most duplicates removed to accommodate a ton of blocks.
This is also useful for kaizo hacks involving the cap cannons, you can design a level in a way that the player cannot use the upwards-facing cap cannons as platforms but as a 1-use launcher the player has to remain in midair most of the time.
Once that gets release, I would. Just that the exiting timers and potentially the centering code may be needed to be modified along with the powerup check (make it so that it forbids small mario (RAM_19=$00)). The last time I tested that, mini mario had the same hitbox as small mario.
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 $01B8B1Change 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.