| Name: | Level Constrain v3.4 |
| Author: | HammerBrother |
| Added: | |
| Version History: | View |
| Tool: | Asar |
| Requires Free Space: | Yes |
| Bug Fix: | No |
| Featured: | No |
| Description: | Unlike screen constrain, this patch constrains the player and sprite's interaction with blocks within the level (properly, check out the first gif to see why). V3 update: Now works properly with LMv3.00 dynamic levels patch. Tester's Note: Does not work with Morton, Roy, Bowser, and Reznor. 3.1 update: now you can disable the patch's effect via a RAM if you want to have only specific levels not to have this effect. 3.2 update (removed because crashing): freeram is now bit-side-based, to make disabling each individual of the 4 sides possible. 3.3 update: fixed potential crashing issue. 3.4 update: fixed a bug that Super/Cape/Fire mario, when not crouching, interacts with the 2nd-bottomost row when he should only interact the bottom row. It now uses fastrom (happens when JMLing back to SMW code). Github: https://github.com/GhbSmwc/SMW_LevelConstrain |
| Tags: | anti-cheat lorom physics player sa-1 sprite |
| Comments: | 19 (jump to comments) |
Download
219.19 KiB | 339 downloads
Comments (19)
This is the case even when I have !Setting_LevelConstrain_RAM_Based = 1 and haven't set the RAM in a level. (The RAM isn't being set by anything else, either.)
I first tested on FastROM with... well, nearly 150 other patches. Yet sprite performance is actually fine even when every single other patch is applied, even in situations with heavy sprite usage. When I add this patch, though, it quite noticeably takes a dip. When I add this + the screen-scrolling pipes fixes patch, it can be almost unplayable in situations with heavy sprite usage.
Even just on their own on a clean rom, there seems to be a significant amount of new lag when using these two patches in situations with heavy sprite usage. It becomes much worse when used with other performance-intensive patches, like NMSTL.
I'm aware of that but it's a global change i.e. sprites also are affected by it.
Replaced the very specific tags over the level and under the level with physics, fixed a missing SA-1 conversion.
Definitively a useful patch in certain cases. Having it dependent on RAM also fixed incompatibility with Mode 7 bosses and is a useful addition in general (as you sometimes want to go above the level but not always).
Possible suggestions: Use two or even four flags: One for each direction as e.g. you sometimes want to go above but not below the level. The code also could be improved a bit as you can only change the data bank with
PLBwhereas neitherJMLnorJSLcan change it.The 4 directional can be emulated via having blocks that enable/disable the flags and the player triggering it at specific locations of the level.
Replaced the very specific tags over the level and under the level with physics, fixed a missing SA-1 conversion.
Definitively a useful patch in certain cases. Having it dependent on RAM also fixed incompatibility with Mode 7 bosses and is a useful addition in general (as you sometimes want to go above the level but not always).
Possible suggestions: Use two or even four flags: One for each direction as e.g. you sometimes want to go above but not below the level. The code also could be improved a bit as you can only change the data bank with
PLBwhereas neitherJMLnorJSLcan change it.A better way to do this is by “defaulting” the value to #$01 on the overworld init (gamemode $0E), and only in levels you want this off, you use STZ !Freeram_LevelConstrain (don't forget to have !Freeram_LevelConstrain = $60 at the top).
Yes, but remember that for levels you do want its effects in other levels, you set this to #$01. This means if you go to a level that doesn't have this effect, then go to a level that is intended to have that effect, it remains off if you leave the RAM set to #$00.
To turn the effects off, just have the RAM it's using set to $00. It's explained on the ASM patch:
However, because the patch assumes that horizontal levels always have a bottom border at Y=$01A0, this is not the case if you change the “Horizontal Level Mode” in “Change Properties in Header” to other than the first option saying “Level height=01B tiles, Max H-Screens=20”.
Therefore if the player or sprite is below Y=$0190 (2D Y-positions values increases as they descend), the player/sprite will only interact with blocks at Y=$01A0, causing the bottom of the newly expanded area useless. Currently, I'm trying to find a RAM value that is based on the level dimension setting.
This is what needs to be changed:
..HorizontalLvl REP #$20 LDA #$0190 CMP $96 ;\Check if bottom boundary is is above mario BMI ..SetYPosCollisPoint ;/(mario is too far below) ..NormalYPosition LDA $96 ..SetYPosCollisPoint CLC ADC $00E89C,x STA $98Sprite_HorizLvl_blk_interYPos: ;>$0194D4 LDA #$0000 ;>Top of level CMP $0C ;>Collision point Y position BPL .Exceed ;>If top of level below collision point (collision is above) LDA #$01AF ;>Bottom of level CMP $0C ;>Collision point Y position BMI .Exceed ;>If bottom of level is above collision point (collision is under) SEP #$20 JML $0194DD ;>Continue on with code .Exceed STA $0C .Align16x16 SEP #$20 AND #$F0 ;\So it doesn't glitch out with blocks ($0194C5) STA $00 ;/that need 16x16 alignment JML $0194DD ;>Continue on with codeGood job.